Community
Participate
Working Groups
As per Pascal's suggestion, we should investigate timing out and closing the plugin JAR files which underly the BundleFiles. Say after 5 min of not being accessed simply close the JAR and lazily reopen if it is ever accessed. The key here is that once a plugin is up and running (with its images and code loaded) we seldom need to revisit the JAR having it open is just wasting space.
just as a reminder. We may not be able to do this for JXEs as they are memory mapped.
If we are not able to ship as jars, this will become more important. Marking as 3.1
Pascal, I am not against this enhancement. But I fail to see why it is more important if we do not ship as jars.
If we ship eclipse as jars, then all the files that were at the root become files in the jar. Therefore opening them, no longer cost an os handle. That's why if we do not ship as jar, it becomes more important to close our jar to reduce the possibility to run out of file handles. After discussing this option with other team members it seems that the investigation still worth it since even if we ship as jars.
bug 113718 tries to solve a similar problem. It has a subtle difference because it limits the number of open jar files. This bug wants to put a limit on the amount of time an idle jar stays open. Bug 113718 has been marked fix. I'm not sure we want to support both approaches to solve this problem. Can we close this as a dup of 113718 or close as wontfix?
I would rather take ownership of it rather than closing as wontfix.
how about marking as 3.3?
Not for 3.3.
I know several products have been running with bug 113718 to solve issues with too many jar files open. Closing as wontfix, we can reopen later if there is an important usecase where the fix in bug 113718 is not sufficient
