Community
Participate
Working Groups
I was mirroring eclipse update site (all features), and it completed with errors. The eclipse/configuration.#############.log file contains tens of following: !ENTRY org.eclipse.update.core 4 0 2005-08-15 12:57:06.596 !MESSAGE [Too many open files] !STACK 0 java.util.zip.ZipException: Too many open files at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:204) at java.util.jar.JarFile.<init>(JarFile.java:132) at java.util.jar.JarFile.<init>(JarFile.java:97) at org.eclipse.update.core.JarContentReference.asJarFile (JarContentReference.java:142) at org.eclipse.update.core.JarContentReference.peek (JarContentReference.java:324) at org.eclipse.update.internal.mirror.MirrorSiteFactory.parseDownloadedPluginsAndF ragments(MirrorSiteFactory.java:127) at org.eclipse.update.internal.mirror.MirrorSiteFactory.createSite (MirrorSiteFactory.java:79) at org.eclipse.update.internal.mirror.MirrorCommand.getMirrorSite (MirrorCommand.java:124) at org.eclipse.update.internal.mirror.MirrorCommand.run (MirrorCommand.java:56) at org.eclipse.update.standalone.ScriptedCommand.run (ScriptedCommand.java:64) at org.eclipse.update.standalone.StandaloneUpdateApplication.run (StandaloneUpdateApplication.java:47) at org.eclipse.core.internal.runtime.PlatformActivator$1.run (PlatformActivator.java:226) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:376) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334) at org.eclipse.core.launcher.Main.basicRun(Main.java:278) at org.eclipse.core.launcher.Main.run(Main.java:973) at org.eclipse.core.launcher.Main.main(Main.java:948) This was for plug-ins contained in 200-300 features that are on the site. I suppose the problem may be hit for a given version it the product is sufficiently large.
I repeated the mirroring process few more times, but it always hits this issue. Hundreds of java.util.zip.ZipException are logged, so I am unable to completely mirror the eclipse updates site. My local mirror already contains contents of eclipse testUpdates, and together with updates it is too much to handle. Looking at the code, ,some access to Jar files is controlled by a class. JarContentReference class contains a list of all JarFile opened. The size of the list is unbound, and the files are closed only on platform shutdown. Second problem is that not all reading from Jars occurs using JarContentReference. ContentReference API contains asURL() method that in this case returns URL of the form jar:file:..., and some parts of Update code open URLs directly using Java APIs. The OtherResponse class does url.openConnection() in case of jar:file: URL. That obviously presents a challenge when to close the files or how to keep track of them. I think the APIs should not open URLs directly at all. It would be best if they are completely removed from APIs as they are opened to easily. A symbolic equivalent should be introduced that could be implemented only by each protocol/transport implementation. This would ensure that the Response classes that already exist in Update would have their Request equivalent and both could be use component-wide across update. Each implementation could implement its own caching and recovery strategy, that in the long run would eliminate duplicate http connections or too many jar files open.
I used Sun's VM. Probably 1.5_04, but I am not sure.
Will this bug be addressed in a maintenance release of 3.1? Has it been addressed in versions of Eclipse beyond 3.1?
This was fixed in Eclipse 3.2.1 *** This bug has been marked as a duplicate of bug 150994 ***
