________________________________ From: Christopher Schultz <ch...@christopherschultz.net> Sent: 14 January 2020 16:30 To: users@tomcat.apache.org <users@tomcat.apache.org> Subject: Re: Class loader takes long time after server inactivity - Tomcat Version 9.0.10
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark, On 1/14/20 9:58 AM, Mark Thomas wrote: > On 14/01/2020 14:40, Niall Fitzpatrick wrote: >> >> >> >> >>> Hi Folks, >>> >>> >>> >>> I have a web application that, after a period of inactivity >>> (1-2hours), will stall for 3 – 35 seconds upon the first new >>> session. All subsequent sessions will not experience this delay >>> unless another period of inactivity occurs. >>> >>> >>> >>> I’ve found that the delay occurs when loading jars that live in >>> the WEB-INF/lib folder. >>> >>> >>> >>> The issue doesn’t occur when the server is first started. Only >>> after a period of 1-2 hours approx. will the next session >>> experience the delay when loading a jar. This leads me to >>> believe that when the server is started ‘knowledge’ of the jars >>> might be cached, however, after a period of inactivity this >>> cache may expire. The result of this is that the next session >>> after this period causes the lib folder to be searched again >>> which seems to take the 5-35 seconds. >>> >>> >>> >>> My question: Is this theory above correct, and if so, is there >>> a way to configure Tomcat such that this cache doesn’t expire >>> so that it doesn’t need to be re-populated when a new session >>> begins? >> >> It depends. Which resources are slow to load? >> >> Mark >> >> Hi Mark, > > Thanks for the additional info. That helps a lot. > > Apologies for the following information dump but there are lots of > factors to make you aware of. > >> Doesn't seem to matter which Jar. At first it happened when >> loading a class from my own custom Jar. > > That should be a one-time cost. Once loaded, classes remain in > memory until the web application is stopped. > > Finding the right class can be expensive. The more JARs the > application has, the more expensive the process will be. Tomcat > does cache the list of entries in a JAR for a short period of time > to speed up this search. If the application has been completely > idle for a while then you will see a pause on the first attempt to > load a class while those caches are refreshed. > > Tomcat can't hold the cache for too long as it uses memory and > locks files. > > One possible solution is to use a ServletContextListener and load > the classes you know will be / are likely to be required when the > application starts. > >> I removed this code to determine if it was the cause. However, >> then I found the same problem further downstream. When calling >> DocumentBuilderFactory.newInstance() which lives in >> xml-apis-1.3.04 The delay of 5-35 seconds occurred here instead. > > Ah. That will probably be the biggest culprit. > DocumentBuilderFactory uses an SPI mechanism to find the correct > instance to create. That SPI mechanism involves searching every JAR > for a configuration file. The expectation, although it may not be > documented as clearly as it should, is that > DocumentBuilderFactory.newInstance() is called only once during the > lifetime of a web application and the result cached. +1 But 5-30 seconds is a looong time. Niall, any chance you have a particularly slow disk, loaded server, or maybe a network share where these files are located? - -chris Hi Chris, I don't believe so. A customer reported the issue, and I was able to recreate it on our own test environment. I will say this - the web application has 263 jars in it's lib folder. That's got to be a lot of searching. Thanks for everyone's suggestions. I'm going to try the wrapper class solution where I can cache the result. I'll send an update with what I learned. Niall --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
