The PrintServiceLookupProvider can spawn 2 threads on WIndows and one thread on Linux. These threads are connected to the classloader of the web application. During undeployment the app classloader gets removed together with the two orphaned threads by the Tomcat.
Looks like the tomcat has special machinery to workaround such threads: https://cwiki.apache.org/confluence/display/tomcat/MemoryLeakProtection#MemoryLeakProtection-cclThreadSpawnedByJRE But it should be updated each time we add/update/rename the threads in the JDK. So JreMemoryLeakPreventionListener can be updated to solve this problem, but it will be good to reset the ref to the app class loader as we usually do for our internal threads. The change updates threads to use the root thread group and null context class loader. A similar pattern is used here: https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.desktop/share/classes/com/sun/imageio/stream/StreamCloser.java#L89 @aivanov-jdk please take a look ------------- Commit messages: - cleanup - Update PrintServiceLookupProvider.java - Update FlushCustomClassLoader.java - cleanup and test - Update PrintServiceLookupProvider.java Changes: https://git.openjdk.java.net/jdk/pull/5939/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5939&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273831 Stats: 120 lines in 3 files changed: 104 ins; 3 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/5939.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5939/head:pull/5939 PR: https://git.openjdk.java.net/jdk/pull/5939
