Am 22.07.25 um 17:59 schrieb Daniel Sheridan:
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?
I forgot the current situation with respect to caching negative class
loading results in Tomcat, but it might be a search for non-existing
classes or resources.
Activating verbose or trace (FINE, FINEST) logging for the Tomcat class
loaders could shed some light on it, but better not on a busy instance.
Best regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
