[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #7 from Mark Thomas --- This issue is fixed. As per comment #4: Note that with the memory leak protection in place or when running on Java 9 onwards, the TCCL will have to be set on a ForkJoin thread. Please follow up on the users mailing list and include the simplest possible test case that demonstrates the problem you are seeing. If that discussion determines that you have found a bug then this issue can be re-opened or a new issue created as appropriate. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224 soheil rahsaz changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from soheil rahsaz --- I'm experiencing the same issue on Tomcat 9.0.21 and JDK 14.0.1. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224 Mark Thomaschanged: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Mark Thomas --- Protection disabled in Java 9 onwards in: - trunk for 9.0.7 onwards - 8.5.x for 8.5.30 onwards - 8.0.x for 8.0.51 onwards - 7.0.x for 7.0.86 onwards FYI: Useful test cases for exploring memory leaks: https://github.com/markt-asf/memory-leaks -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224 --- Comment #4 from Mark Thomas--- The JNDI lookup must be happening on the ForkJoin Thread. The JNDI depends on the TCCL being set and it is no longer set on a ForkJoin thread (to avoid the memory leak). I'll confirm the Java 9 fix and then disable the protection for Java 9 onwards. Note that with the memory leak protection in place or when running on Java 9 onwards, the TCCL will have to be set on a ForkJoin thread. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224 Behrooz Nobakhtchanged: What|Removed |Added Status|NEEDINFO|NEW --- Comment #3 from Behrooz Nobakht --- Extracting a minimal reproducible example is quite difficult for me. I will explain the current situation as is. Tomcat is used with a custom server.xml: Please note the definition of `Resource` in above. When accessing one of the HTTP endpoints on the app, a business objects wants for the first time to gain access to the JNDI resource `java:env/comp/UserTransaction`. Because there's no custom definition of NamingContext provider API, the default is picked by javax.naming.InitialContext. This is L313 of javax.naming.InitialContext in Java 1.8.0_172: defaultInitCtx = NamingManager.getInitialContext(myProps); `myProps` is filled by Catalina bootstrap to point to Apache Naming implementation. Going further down the stack, you will reach com.sun.naming.internal.VersionHelper12 at L61: return loadClass(className, getContextClassLoader()); The fix for ForkJoinWorkerThreadFactory means that there will be no context class loader, which means it will be "system" class loader and eventually leads to ClassNotFoundException. Hope this clarifies further the issue. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224 Remy Maucheratchanged: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Remy Maucherat --- Ok so the revision is here: http://svn.apache.org/viewvc?rev=1778061=rev It is supposedly no longer needed on Java 9+, so a subsequent revision could be made to avoid it in that case. Note that you also have a setting on JreMemoryLeakPreventionListener to disable it. I don't get how this, by itself, then causes the naming context factory failure. Please explain how to reproduce it. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224 --- Comment #1 from Behrooz Nobakht--- Adding more context into this: The reason for this change seems to be this JDK bug: https://bugs.java.com/view_bug.do?bug_id=JDK-8172726 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224 Behrooz Nobakhtchanged: What|Removed |Added CC||nob...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org