Just noticed another thread on this topic: RE: Tomcat discards and reloads the 
jar files from the webapps folder.

Setting the Engine attribute backgroundProcessorDelay to 90s does reduce the 
open/close cycle of the jars.

The other thread also mentioned a potential configuration to keep the jars open 
longer by default. This could be helpful - not sure we need to close them at 

Alternatively, would there be any gain to 'explode' the jars into class files 
on the filesystem? 

-----Original Message-----
From: Rhuberg,Anthony <anthony.rhub...@cerner.com.INVALID> 
Sent: Wednesday, October 09, 2019 2:17 PM
To: users@tomcat.apache.org
Subject: Performance test with Tomcat 9 shows increased cpu/disk usage because 
of repeated opening/closing of jars in WEB-INF/lib

In the last few months we migrated our web application from Tomcat 7.0.55 to 
Tomcat 9.0.19 (26). That transition was relatively straightforward until we 
reviewed the results of our performance tests. Those tests showed an increase 
in CPU usage and disk I/O on our Windows 2012 server. When we switch back to 
Tomcat 7, the metrics for CPU/disk usage were significantly lower (similar to 
previous tests).

As we investigated the cause of the increase in cpu/disk usage we found the 
tomcat process was repeatedly opening and closing the jars of our web 
application. The process profile showed all the jars in WEB-INF/lib being 
closed and reopened within seconds while the application was processing 
requests (and to some extent when quite). Now we are trying to determine why.

We have a general understanding that the WebappClassLoaderBase.java 
implementation changed in Tomcat 8.5. The Tomcat 7 implementation provided for 
the configuration of  jarOpenInterval (which we used the default = 90s). The 
latest implementation appears to track the jar modification times with a hash 
map called jarModificationTimes, but we are unable to find a similar 
time-to-live configuration or what triggers the lifecycle listener to close the 
jars (what calls WebappClassLoaderBase.modified() or destroy()) - assuming we 
understand this lifecycle behavior.

The server is configured mostly with default settings. The Context reloadable 
property is NOT set. We have tried increasing the cache time of the Resources 
cacheTtl property as the default of 5s seemed close to the time the jars were 
reloaded. We have not been successful.

What is the cause of the repeated reloading of our web application jars? What 
can trigger the class loader to close all the file handles related to the jars 
in the web application WEB-INF/lib directory - and then open them again within 
a few seconds?

CONFIDENTIALITY NOTICE This message and any included attachments are from 
Cerner Corporation and are intended only for the addressee. The information 
contained in this message is confidential and may constitute inside or 
non-public information under international, federal, or state securities laws. 
Unauthorized forwarding, printing, copying, distribution, or use of such 
information is strictly prohibited and may be unlawful. If you are not the 
addressee, please promptly delete this message and notify the sender of the 
delivery error by e-mail or you may call Cerner's corporate offices in Kansas 
City, Missouri, U.S.A at (+1) (816)221-1024.

To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to