We are using WSO2 ESB 4.8.1. We have developed a proxy for reading a CSV file and inserting into a database table. File is configured to be MOVED to a history folder after processing. When the file is dropped in the FTP folder, a lock file would be created. It normally will be removed when the processing is over. But now it never gets deleted and the lock file stays as it is in the input folder. We couldn't find out the reason for the same. Please help to solve this issue.
You can also try to set transport.vfs.Locking parameter to disable creation of a .lock file when its processed.
Hope that helps
This is a known error in ESB 4.8.1. There is a patch available from WSO2 support, but that requires having a support contract. You can also use a newer version of the ESB since 4.8.1 is already quite dated, using 4.9 or 5.0 you should not run into these problems anymore.
Related
I'm trying to open my newly installed Postman when an error occurs which says something like this:
**Could not open Postman**
Error: Migration: IndexedDB schema migration failed. IndexedDb was not upgraded succesfully after `dexie.open`.
Please try restarting the app. If the issue persists, please refer to http://go.pstmn.io/troubleshoot-could-not-open
As it says, the error really persists. The website above only provides suggestions like "reinstall the app" "upgrade the app", which are not really helpful. And as I dig into the Internet, it occurs to me that such error hardly happens (found nobody have the same question like me).
"IndexedDb" was mentioned in the error message, and I just know (from the Internet) that it's a nosql database provided by explorer. Maybe the problem can be solved by reinstalling the database, I guess?
I had a similar problem and found this description: https://github.com/postmanlabs/postman-app-support/issues/4897
Short answer is, delete the Postman configs directory at ~/.config/Postman (for Linux) and then try running again. This will delete any saved Postman data you have, but for a newly-installed instance that's not an issue.
Go to installation folder of Postman:
C:\Users\Davoud\AppData\Local\Postman
delete the older version's folder. It fixed my problem. Actually I also deleted update.exe too.
Can you try just by deleting the “Postman” folder or renaming it to “Postman.old” from below two locations and then reinstall the latest version from here and see if that helps?
C:\Users\<user>\AppData\Local and C:\Users\<user>\AppData\Roaming
I tried it as I was facing the same issue and, it solved for me.
Use this: It worked for me.
pkill -fi Postman
For Windows 10 - in my case, I have to:
Open Task Manager and kill/end the Postman application.
Go to %appdata% and search the "Postman" folder.
Inside "Postman" folder, select the "Postman_Config" folder1. Delete it.
Try to open your Postman instance again.
1 The "Postman_Config" folder contained (in my case) another folder called "0" and inside this folder, an "userconfigs.json" file - which only contained these characters:
{}
If you have additional information,please, make a copy of these files in order to have a backup - if needed.
For Windows -
Kill the process that says, postman from the task manager
Run the installer again, it resolved the issue for me.
disable hardware acceleration in the Postman menu in macOS, or the Help menu in Windows or Linux.
I had a similar problem installing Postman when I was on a VPN (on Windows). It started up but then got a popup error saying "TypeError: Cannot read property 'id' of undefined," and a blank white screen afterwards. So I uninstalled it, deleted any Postman folders, turned off the VPN, and re-installed it with no problems! After it installed successfully, I was able to turn on my VPN and had no further issues.
For reference, I had these errors in my C:\Users\<user>\AppData\Roaming\Postman\logs\renderer-requester.log file
[20076][1645655031650][requester][info]["Migrations: Committing IndexedDB upgrade"]
[20076][1645655031665][requester][error]["Could not complete migration.",{"name":"Error","message":"Migration: IndexedDB schema migration failed. IndexedDb was not upgraded successfully after `dexie.open`.","stack":"Error: Migration: IndexedDB schema migration failed. IndexedDb was not upgraded successfully after `dexie.open`.\n at file:///C:/Users/<user>/AppData/Local/Postman/app-9.13.0/resources/app.asar/js/scratchpad/scratchpad.js:477:1448541\n at file:///C:/Users/<user>/AppData/Local/Postman/app-9.13.0/resources/app.asar/js/scratchpad/scratchpad.js:2:3000934\n at Ve (file:///C:/Users/<user>/AppData/Local/Postman/app-9.13.0/resources/app.asar/js/scratchpad/scratchpad.js:2:2996146)\n at ze (file:///C:/Users/<user>/AppData/Local/Postman/app-9.13.0/resources/app.asar/js/scratchpad/scratchpad.js:2:2996903)\n at IDBOpenDBRequest.<anonymous> (file:///C:/Users/<user>/AppData/Local/Postman/app-9.13.0/resources/app.asar/js/scratchpad/scratchpad.js:2:2997272)"},{"0000_initial":"started","0001_add_archived_resources_table":"started","0002_add_variable_sessions_table":"started","0003_add_editor_tables":"started"}]
[20076][1645655031673][requester][error]["Migration: Could not complete migration.",{"name":"Error","message":"Migration: IndexedDB schema migration failed. IndexedDb was not upgraded successfully after `dexie.open`.","stack":"Error: Migration: IndexedDB schema migration failed. IndexedDb was not upgraded successfully after `dexie.open`.\n at file:///C:/Users/<user>/AppData/Local/Postman/app-9.13.0/resources/app.asar/js/scratchpad/scratchpad.js:477:1448541\n at file:///C:/Users/<user>/AppData/Local/Postman/app-9.13.0/resources/app.asar/js/scratchpad/scratchpad.js:2:3000934\n at Ve (file:///C:/Users/<user>/AppData/Local/Postman/app-9.13.0/resources/app.asar/js/scratchpad/scratchpad.js:2:2996146)\n at ze (file:///C:/Users/<user>/AppData/Local/Postman/app-9.13.0/resources/app.asar/js/scratchpad/scratchpad.js:2:2996903)\n at IDBOpenDBRequest.<anonymous> (file:///C:/Users/<user>/AppData/Local/Postman/app-9.13.0/resources/app.asar/js/scratchpad/scratchpad.js:2:2997272)"},{"0000_initial":"started","0001_add_archived_resources_table":"started","0002_add_variable_sessions_table":"started","0003_add_editor_tables":"started"}]
[20076][1645655031676][requester][info]["booted - requester"]
[20076][1645655031686][requester][error]["Could not complete migration.",{"name":"TypeError","message":"Cannot read property 'id' of undefined","stack":"TypeError: Cannot read property 'id' of undefined\n at t.default (file:///C:/Users/<user>/AppData/Local/Postman/app-9.13.0/resources/app.asar/js/scratchpad/scratchpad.js:477:1193039)\n at
......
we are using WSO2 EI version 6.1.1 and fileconnector 2.0.10
We are trying to use the readSpecifiedLine operation from file connector but it always read the entire file. In this particular case we are trying to read a CSV skipping the header.
<fileconnector.readSpecifiedLines>
<source>{$ctx:sourceFile}</source>
<contentType>text/plain</contentType>
<start>2</start>
<end>3</end>
</fileconnector.readSpecifiedLines>
Did someone was able to use this operation successfully, can't find much on google either. thanks.
This issue is fixed with the version 2.0.12. Please download and redeploy the latest connector [1] from WSO2 store.
[1] https://store.wso2.com/store/assets/esbconnector/details/5d6de1a4-1fa7-434e-863f-95c8533d3df2
This is already a bug. Reported bug Jira Id.
https://wso2.org/jira/browse/ESBCONNECT-271
WSO2 XSLT mediator Parsing Issue in the below line
<xsl:template match="Id[some $sib in preceding-sibling::Id satisfies deep-equal(., $sib)]"/>
We have two servers in one server there is no issue and the transformation has happened successfully without node-set(). In the another WSO2 server there is an parser Issue. Unable to pase $ expected ] and it is asking for a node-set() in XSLT.
I have compared the conf files and repository files between the two servers and both are same. Even dropins and lib files are also same. We are just confused to sort out the issue since it is asking for node-set() in one server and in another server it is throwing exception because of node-set(). Kindly help on it.
Is it possible to copy the working instance from one server to another server and then try testing.
If that is not possible then can you confirm whether other XSLT's are working fine or not.
Hi the issue has been solved. Since we were using Linux environment it was taking the Saxon processor by default where as in Windows wso2 takes the xalon processor to process the xslt. So in linux we have pointed manually in the wso2server.sh file to manually point to xalon processor and it is working fine. Thanks..,
What is the best / flexible WSO2 upgrade strategy?
Because now we are upgrading WSO2 DSS 3.0.1 to DSS 3.1.1, therefore there is some difficult changes in dbs file one by one
wso2dss-3.0.1
<data name="BASE_PERSON_DataService" serviceNamespace=
"http://company.mn/base/BASE_PERSON">
wso2dss-3.1.1
<data description="multiple services per each table" enableBatchRequests="false"
enableBoxcarring="false" name="BASE_PERSON_DataService"
serviceNamespace="http://company.mn/base/BASE_PERSON" serviceStatus="active">
What is the easy way, we have many data services (dbs files)?
Regards,
Eba
As far as I know, there is usually no standard migration tool or procedure available. Check that the newer version uses a compliant schema for the wso2 registry database and so on; maybe it's the same or you just need to create new additional tables. Sometimes you find things like migration scripts in the dbscripts folder. You should also check for differences in newer xml configuration files, and adjust your older custom configuration to the new format (usually few or no changes could be required). As far as the artifacts are concerned, I never heard of any way to convert them. If there are many of them, I would probably try some script and regex to batch modify and adjust them to the new format.
These are the steps you should follow if you are upgrading
Step 1 - Deploy artifacts {dbs/datasource/drivers}
Cappy the deployed data services from current installation to new installation by copying repository/deployment/server folder.(all dbs files are backword compatible so what ever worked in WSO2 DSS 3.0.1, should work on DSS 3.1.1) Also note you need to copy data source configuration properties if you have created carbon data sources therefore copy master-datasources.xml from repository/conf/datasources to the new installation.
Also Copy all the content of repository/component/lib to the new installation to ensure the the jdbc drivers are properly installed.
Step 2- Change the configuration files
Apply the same changes you have done to configurations files inside OLD_DSS/repository/conf to NEW_DSS/repository/conf (if you have done any such to any configuration files)
Note - If you have done registry mounting make sure you apply to the new installation as done before by changing relevant configuration files such as
carbon.xml,axis2.xml,user-mgt.xml,mgt-transports.xml
We have an MSI to install windows service on client machine.
Windows service calls the web service of our server to perform operations.
Initially both the MSI and web service were built using .NET 2.0 framework.
Last quarter we upgraded our systems to .NET 4.0. Though our web service is still ASP.NET i.e. asmx (and not WCF). Also I did set framework 4.0 as the prerequisite for MSI to install.
One of our clients reported this issue:
Client was using .NET framework 2.0, and had the older version of MSI installed in his system.
When he tried to installed the .NET framework 4.0 version of the MSI, was prompted to install framework 4.0 (because of the prerequisite). Once the framework installation finished, he tried to install the MSI and got this error. Can someone please guide me to the resolution. I can provide details if needed.
EDIT 1:
On more research, I found it is my AppName.installstate file. Uninstall removes this file, but upgrade does not do it. The file is lying in the install directory. On a closer look I can see "http://schemas.xmlsoap.org/soap/envelope/:Envelope" in the file contents. Any pointer would be greatly appreciated.
EDIT 2:
Custom action Install creates AppName.installstate file and custom action Uninstall deletes the file. In my case, I am doing an MSI upgrade which does not do anything to this file. When I compared the installstate file from 2.0 and 4.0 (both installed manually), I could see a huge difference in the XML syntax, schema and contents, the reason, I am getting serialization error. Now I need to know why AppName.installstate is not getting overwritten when upgraded. Doing lot of google, but landing nowhere.
Looked at MSI install log, but no useful information.
Eureka !!!!
I found solution to my problem.
Root cause of the problem:
MSI generates an XML file during installation (application_name.installstate), which stores information MSI uses during install, uninstall, rollback. The format of this XML file is completely different between .NET 2.0 and .NET 4.0 i.e. MSI developed using VS2005 and VS2010.
Because 4.0 frmaework is not able to understand the file generated by Old Framework version (2.0), we are getting the error saying “Not able to serialize the Type of the Installstate file”.
Though there is no documentation available online for this, there is this discussion I found > http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/bedbb8bd-dad5-4bcb-a87a-ac69386669b4/
Solution I tried (I would call it work-around):
During installation of the New version, I am explicitly replacing the old XML file with the new format (4.0). i.e I included application_Name.installstate file (generated by new version) in my package, so it overwrote the old file while upgrade.
MSI got installed without any error and is running successfully.
Reply here if anybody needs detail on both problem and solution.
This error message has nothing to do with the installer per the 1001 error message. The problem is fully inside your service.
Your service's OnStart method should be doing nothing but spinning up a background process and returning success start to the service control manager as quickly as possible. There shouldn't be any long running code in that critical path as the SCM will only wait so long before assuming there was an error starting the service.
Refactor your service to run the job on another thread and the install will successfully install. From there you can focus on the real problem of what's going on in your DeSerialization process.