[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: RFR: 8273831: PrintServiceLookup spawns 2 threads in the current classloader, getting orphaned
From:       Alexey Ivanov <aivanov () openjdk ! java ! net>
Date:       2021-10-29 9:52:09
Message-ID: wG4LTv1th8JmfFXPmt_lz6b24xXV7WcfDGUXvxoh4gk=.73f8110a-b525-4e3f-8670-dad38af40141 () github ! com
[Download RAW message or body]

On Thu, 14 Oct 2021 05:43:53 GMT, Sergey Bylokhov <serb@openjdk.org> wrote:

> 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

Marked as reviewed by aivanov (Reviewer).

Sorry for my delayed review, looks good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5939


[prev in list] [next in list] [prev in thread] [next in thread]