Community
Participate
Working Groups
We are starting to see problems with Osgi opening too many files, the problem is typically exposed by launching eclipse inside of eclipse. Our product builds on top of (Eclipse and Webtools) adding a lot of more plugins. The exceptions that we are seeing are similar to: - - - - - - - - - - - - STACKTRACE - - - - - - - - - - - !ENTRY org.eclipse.core.runtime.compatibility.registry 4 0 2006-10-11 08:46:08.744 !MESSAGE FrameworkEvent.ERROR !STACK 0 java.util.zip.ZipException: Too many open files C:\IBM\MyProduct\eclipse\plugins\org.eclipse.core.runtime.compatibility.registry_3.2.1.R32x_v20060907\runtime_registry_compatibility.jar at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:238) at java.util.zip.ZipFile.<init>(ZipFile.java:268) at org.eclipse.osgi.framework.util.SecureAction.getZipFile(SecureAction.java:226) ... ... - - - - - - - - - - - - STACKTRACE - - - - - - - - - - - As a workaorund we are using -Dosgi.bundlefile.limit=100 as a VMArgument in the configuration. But eclipse-osgi should contain more reasonable defaults and not require this new parameter just to allow it to run.
you have to define reasonable. Setting at parameter has side effects that will disappoint other people. If we set the value to what you want, we'll get bug reports asking for it to be set to a differnet value. How can we win this game?
Is this not a duplicate of Bug 140549? Business Partner using an IBM product built on the Eclipse + most of Callisto base (we add more of course). They have this problem when using a German language installation and trying to start a runtime workbench to test their plugins. So translations seem to drive this a bit as well as a PDE launch. Why not pick a number that is 2X what Eclipse + Callisto needs, assuming that will be at least 100; then at least the "big boy" we have works when running in German. Or try a circular test - a non-English Eclipse + Callisto layer and get a plugin or three in the workspace to test. That is what triggered the Partner problem. The product started fine, but you could not launch the runtime workbench. If Eclipse + Callisto starts a runtime workbench in a non-English system, maybe you should double the number from there (if you can tell how many files were open). The rest of us need room to grow.
Resolving as dup of bug 140549. There really is no good answer for providing a default here. In testing some real products it was found the setting of osgi.bundlefile.limit = 100 had some real performance issues. In that particular situation a value above 200 seemed to give reasonable performance. If we are forced to provide some default then I would lean toward a very high number (even above 500). But I'm not sure what the different file limits are of the different platforms we support. In the end we would likely need to supply a different default for each of the platforms we support. *** This bug has been marked as a duplicate of bug 140549 ***
