Community
Participate
Working Groups
I am uncertain at the direct cause of this issue. However, I am working on a project that entails a long-running daemon that accepts TCP connections using netty and as a result of requests received processes binary documents using Apache TIKA, in combination with a database connection to a PostgreSQL database. However, it seems that at least the Runnable JAR-generator is involved and especially the JarInJarLoader. The problem: When I start the Runnable JAR and fire many requests on the TCP socket, at some point (quite soon, after several minutes), an OutOfMemory error will occur due to GCOverheadException. I debugged the issue and found that a lot of space was occupied by the DeleteOnExit handler which I only use for 2 files. It turned out that there were hundreds of thousands of DeleteOnExit handlers registered for files called jar_cache<random_characters>. Using the code at: http://www.jroller.com/javabean/entry/solving_an_outofmemoryerror_java_6 I was able to unregister these handlers. However, the OutOfMemory errors were not resolved by this. Using the HeapDumpOnOutOfMemoryException option I could obtain a heap dump when the heap space would run out (set at maximum 2GB). This results in a heap dump hprof file of around 2GB, but when loading this file into the memory analyzer in Eclipse, a mere 60MB of data usage is shown. So apparently, the rest of the data is filled by disposable data. I have not been able to resolve that issue directly. However, it turns out that when I run that exact same project from within Eclipse, this error does not occur. And additionally, when I export the project to a Runnable JAR file where all the dependencies are extracted within that JAR rather then using the JarInJar loader, these issues do not occur either. The DeleteOnExitHandler is running idle, not having to delete any DeleteOnExit files at all, and no OutOfMemory errors occur, regardless of how many requests I fire at the TCP port. So it seems that the JarInJar-loader generates an enormous amount of jar_cache files in /tmp, registers these with the DeleteOnExit system and then deletes them. Why this issue cannot be resolved using the DeleteOnExitCleaner is unknown to me, but it seems related. I'm guessing that maybe the dynamic class loading used in Apache Tika is related to this error, but I am not sure. I hope this description gives sufficient detail to explore this issue. The software I'm working on is unfortunately not open source so I am unable to share this directly. However, if necessary, I can try to build a minimal use case with the same components that exhibits the behavior. If there's any specific non-sensitive information I could collect in order to debug this issue, please let me know.
(In reply to Egbert van der Wal from comment #0) > However, it turns out that when I run that exact same project from within > Eclipse, this error does not occur. I am sorry. I do not get this statement. When you run your program for the scenario mentioned in the first 4 - 5 paragraphs is it with Eclipse or without Eclipse? If you encounter a out of memory exception at run time I don't know how the compiler can help? Thanks
Egbert, you might also want to check if the program is run with a different JRE when you run inside eclipse and outside. Also look for other JVM parameters if any such as heap size etc.
I'm developing a project within Eclipse. In Eclipse, I have launch configurations to run the program. When I use these launch configurations from within Eclipse, the program runs fine without any problems. If I use the Export... -> Runnable JAR option of Eclipse to do this, and run the resulting JAR using java -jar <myfile.jar> I do experience errors. However, if I use the Export... -> Runnable JAR and opt to not use the jar-in-jar-loader by extracting all JARs and including the class files into the resulting JAR, I do not have these issues anymore. I am always using the same JRE, I have only one installed.
Egbert, from your last comment, I understand the issue may be because the jar-in-jar loader is trying to all the classes and that is possibly resulting in the OOME. If that is the case, is there anything do you want the eclipse team to fix it? Please note that the only involvement of eclipse here is the generation of the runnable JAR. What happens after that is wholly with the JRE you use.
I'm seeing something similar, but instead of OOM I'm seeing a huge huge performance problem, but only when I run with Java 8. When I run with Java 7, it's blazing fast. Or if I run without the jar-in-jar feature, that's fast with both Java 7 and 8. But the combination of Java 8 and jar-in-jar runs super slow. For example, it runs in about 10 seconds with Java 7, but more than 8 minutes with Java 8.
(In reply to Lee Breisacher from comment #5) > I'm seeing something similar, but instead of OOM I'm seeing a huge huge > performance problem, but only when I run with Java 8. When I run with Java > 7, it's blazing fast. Or if I run without the jar-in-jar feature, that's > fast with both Java 7 and 8. But the combination of Java 8 and jar-in-jar > runs super slow. For example, it runs in about 10 seconds with Java 7, but > more than 8 minutes with Java 8. Have you seen comment 4? What exactly do you wish the Eclipse team to change?
I thought the jar-in-jar loader code (JarRsrcLoader.java, et.al.) is provided by eclipse. That code appears to have some serious problems when running on Java 8. It seems like someone should at least investigate.
(In reply to Lee Breisacher from comment #7) > I thought the jar-in-jar loader code (JarRsrcLoader.java, et.al.) is > provided by eclipse. That code appears to have some serious problems when > running on Java 8. It seems like someone should at least investigate. You're right. Moving to JDT/UI who own JarRsrcLoader.java.
(In reply to Lee Breisacher from comment #7) > I thought the jar-in-jar loader code (JarRsrcLoader.java, et.al.) is > provided by eclipse. That code appears to have some serious problems when > running on Java 8. It seems like someone should at least investigate. See https://www.eclipse.org/eclipse/platform-text/development/bug-incomplete.htm We will be happy to investigate when we either have a test case or steps.
Created attachment 267842 [details] reproducible test case I attached a jar file that demonstrates the problem. If you run this jar (java -jar bug454619.jar) with Java 7, it takes a second or less. If you run it with Java 8, it takes 20 seconds or so.
Noopur, please investigate when you have time.
Moving back to the inbox.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
