Community
Participate
Working Groups
Build Identifier: 20100617-1415 I've developed an eclipse rcp using osgi. Randomly, upon startup of the deployed application, my customer gets an ZipException like this: !SESSION 2010-08-11 15:53:53.789 ----------------------------------------------- eclipse.buildId=unknown java.version=1.6.0_17 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Command-line arguments: -os win32 -ws win32 -arch x86 !ENTRY be.sidema.crams.controller 4 0 2010-08-11 15:53:55.883 !MESSAGE !STACK 0 java.util.zip.ZipException: Exception in opening zip file: S:\AmpCapTools\Crams\Crams\plugins\be.sidema.crams.controller_0.1.0.jar at org.eclipse.osgi.framework.util.SecureAction.getZipFile(SecureAction.java:264) at org.eclipse.osgi.baseadaptor.bundlefile.ZipBundleFile.basicOpen(ZipBundleFile.java:88) [... callstack ...] Caused by: java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(Unknown Source) at java.util.zip.ZipFile.<init>(Unknown Source) at org.eclipse.osgi.framework.util.SecureAction.getZipFile(SecureAction.java:251) ... 33 more This occurs with all my plugins but also with all other plugins such as "com.springsource.com.mysql.jdbc_5.1.6.jar". The error does not occur upon every start of the application but randomly every now and then. Unfortunately, this happens often enough to irritate my customer. Additionally, it must be said that the drive "S" is a network mapped drive, but then I'm not sure if this is related to this. Reproducible: Sometimes Steps to Reproduce: 1. Start application from network mapped drive. 2. 3.
Do you only see this on startup? This seems like either a VM issue or some issue with your network. On possibility is that our management of the number of open zip file may be causing this to surface. You could try disabling this by setting the following in your config.ini osgi.bundlefile.limit=0
Hi, thanks for the suggestions of the open file limit. I'll discuss this with my customer ASAP. I've just been informed that my contact be out of office until 9/13. So most probably, we'll try this fix upon next update deployment of my application. As for your startup question: Yes, we only see this on my customers machine upon startup. Once the application has started without a glitch, the bundles are all loaded and the problem does not occur anymore. Stopping the application (when it has failed to load the bundles) and restarting it immediately afterwards starts the application as expected...
Looks to be a VM issue. Please let us know if setting osgi.bundlefile.limit=0 helped work around the VM issue.
