>On 7/21/25 20:18 PM, Christopher Schultz wrote: >Daniel and Mark, > >On 7/21/25 12:48 PM, Daniel Sheridan wrote: >>> On 18/07/2025 16:04, Daniel Sheridan wrote: >>> >>>> I definitely think there is something happening on the Tomcat side here >>>> around caching, I've played with some resource caching settings but it >>>> didn't make any difference unfortunately. >>> >>> The flame graph is showing that Tomcat is having to reload the JAR indexes >>> that it uses to find files in JARs (so Tomcat doesn't have to search >>> through every JAR every time it needs to load a new class). >>> >>> That index gets removed (to reduce memory footprint) periodically if it >>> isn't being used. By default this check happens every 10 seconds. >>> >>> To speed things up try experimenting with the archiveIndexStrategy of the >>> Resources element. I suspect you'll want to use "bloom". You will likely >>> see a larger memory footprint but you should also see less (no?) delays. >>> >>> Mark >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >> >> Hi Mark, >> >> I've tried this out and after some initial testing I am seeing improvements! >> I'll be doing some more extensive testing this week, but I'm not seeing the >> delay so far. >> >> On monitoring I don't see any noticeable increase in memory usage so far, >> but that would be somewhat of a concern if increased memory usage is >> possible. Would you have any idea of how much of a potential memory increase >> moving from the default setting to bloom could cause, and if it would be >> just in the short term until the indexes are eventually removed? >> >> I assume that the bloom filter has a longer interval between the index >> checking like you described, so the indexes aren't removed as often? > >My big question is why these classes are being (re?) loaded at intervals. Once >loaded, they should be ... staying loaded. > >Is there some kind of incremental capability being used here? Maybe I >misunderstood the original report. I was thinking: > >1. I login and go to page X and it loads fast 2. Wait 10 minutes 3. I login >and go to page X and it stalls > >Maybe that's not what's being reported? > >-chris > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org
Hi Chris, Exactly, we've answered why the JAR scanning takes so long with Mark's indexing solution, but there's still the question as to why the class is being loaded at all in this case. The steps to make this issue occur are: 1. I login and go to page X and it loads fast. 2. Wait 10+ minutes. 3. I trigger some kind of request to the REST API via interacting with the open page X, e.g. clicking a button that fetches a list from the REST API. 4. The delay occurs (when the indexing settings are set to default), after which the response is returned and the page acts as normal until the next idle period. Would you have any thoughts on this Mark, as to what could be causing the reloading of classes at all when they seem like they should already be loaded? - Dan
