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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
