Details
-
Bug
-
Status: Resolved
-
P4
-
Resolution: Fixed
-
7, 8, 11, 17, 18
-
b22
-
generic
-
generic
Description
ADDITIONAL SYSTEM INFORMATION :
Tested under Tomcat 9.0.52, Windows 10, Coretto-JDK 11.0.12_7
A DESCRIPTION OF THE PROBLEM :
We are using Tomcat 9 and our application uses the following code snippet:
DocFlavor flav = DocFlavor.SERVICE_FORMATTED.PRINTABLE;
PrintService[] printers = PrintServiceLookup.lookupPrintServices(flav, null);
The underlying PrintServiceLookupProvider will spawn 2 threads, namely "PrinterListener" and "RemotePrinterListener" (around line 134 in sun.print.PrintServiceLookupProvider).
These two threads are connected to the classloader of the web-application.
During undeployment the classloader gets removed together with the two orphaned threads.
Tomcat issues a warning on undeployment:
"org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to have started a thread named [PrinterListener] but has failed to stop it. This is very likely to create a memory leak. "
The two threads should not be started in the current classloaders context because that classloader might get deleted on web applications.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the two lines within e.g. a jsp-page within Tomcat:
DocFlavor flav = DocFlavor.SERVICE_FORMATTED.PRINTABLE;
PrintService[] printers = PrintServiceLookup.lookupPrintServices(flav, null);
Undeploy the application and the catalina.log will report the two orphaned threads which get killed.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The application should either be able to get a handle to these threads for a clean shutdown or maybe a flag to prevent starting these two threads.
Another option would be to attach the threads to the root classloader to prevent problems during undeployment of web applications.
ACTUAL -
The two threads are recognized as orphaned and are forcely closed by web container.
CUSTOMER SUBMITTED WORKAROUND :
Before calling PrintServiceLookup.lookupPrintServices(...) we now change the thread's classloader to the parent and afterwards resetting the thread's classloader to the original one.
FREQUENCY : always
Tested under Tomcat 9.0.52, Windows 10, Coretto-JDK 11.0.12_7
A DESCRIPTION OF THE PROBLEM :
We are using Tomcat 9 and our application uses the following code snippet:
DocFlavor flav = DocFlavor.SERVICE_FORMATTED.PRINTABLE;
PrintService[] printers = PrintServiceLookup.lookupPrintServices(flav, null);
The underlying PrintServiceLookupProvider will spawn 2 threads, namely "PrinterListener" and "RemotePrinterListener" (around line 134 in sun.print.PrintServiceLookupProvider).
These two threads are connected to the classloader of the web-application.
During undeployment the classloader gets removed together with the two orphaned threads.
Tomcat issues a warning on undeployment:
"org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to have started a thread named [PrinterListener] but has failed to stop it. This is very likely to create a memory leak. "
The two threads should not be started in the current classloaders context because that classloader might get deleted on web applications.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the two lines within e.g. a jsp-page within Tomcat:
DocFlavor flav = DocFlavor.SERVICE_FORMATTED.PRINTABLE;
PrintService[] printers = PrintServiceLookup.lookupPrintServices(flav, null);
Undeploy the application and the catalina.log will report the two orphaned threads which get killed.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The application should either be able to get a handle to these threads for a clean shutdown or maybe a flag to prevent starting these two threads.
Another option would be to attach the threads to the root classloader to prevent problems during undeployment of web applications.
ACTUAL -
The two threads are recognized as orphaned and are forcely closed by web container.
CUSTOMER SUBMITTED WORKAROUND :
Before calling PrintServiceLookup.lookupPrintServices(...) we now change the thread's classloader to the parent and afterwards resetting the thread's classloader to the original one.
FREQUENCY : always
