-----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 -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4d7L0ACgkQHPApP6U8 pFi3RA//UMh2x8qb5l2/dPeeq6flT9SfneHpMkrwARaZv2KJbKT6esn1xQOm6bBh Ta2luoS8rIExBbjGujLDU+Ko8yXP7gxBSj+PR9b2wKHiygWDTk/bHcGNbmDkztFA ZyrtyOyO6kq4zcHykZxPxAk5RUAFe1Zk9ni6wVHxwqhKA1QE4luv1T13Q6ju/PXV 89sjxw4JXEnNdcV9BvbllrJ/uDwh7xXiHCrvHFxnT9HYvKNzlCQmEQOnrkLGbc9c 6rL7vQ6bo0ubIx8tL036ZPFvZkWERnedHnxR3eyO3/8Y0PDta+Br3wm/o0PDVcX6 esrUZv2UxXT/JVMrWBZWf3dO8IKSj8Q9WjU+CsRoCmrHrlRo+cuCrPj32n78M8NM CWMqpt/oG1mbjBtLRPWXlwvk8R9/qtQKe+1fpCef6cmVjsUXpFfxNgUHxnjw28Oq HkGdQY2Npf2+S3nepBEVQv1WAJMnwcws/Ue7U4qyQJJrKAceeqUBUi8YEWoFEOum RGQxShWb3Qql47ozfp5q6bcfyZPRpEEa0rYBXpTkF0mlAgi3msxNw0hn6nCEcbsI t+BH1GTba0vwR2bpy/5xXaBuGeMtX8/8AG6ol/QyfngRN2xo2ir1Skc6xtClqMJA 1/8FUUv5g3eTzrz11jNMTBWzbTuCLqYwgkzymT0gfeechI8K/dM= =wQwj -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
