Mark,
On 5/31/24 12:44, Mark Thomas wrote:
On 31/05/2024 16:09, Eric Robinson wrote:
The results are looking great so far.
Excellent.
Here's what we know:
Before the patch, we had 2 load-balanced tomcats in production for
this customer. Due to the driver search bottleneck, we were seeing
hundreds of stuck threads during the slowdown periods. To work around
this problem, we threw more tomcats at it. With 6 tomcats, the load
was spread around enough to keep the bottleneck condition from
manifesting badly, and users did not complain as much. We were still
seeing dozens of stuck threads, but not hundreds.
After the patch, we went back to 2 tomcats.
I appreciate the show of faith! I think that is braver than I would have
been but it does rather confirm both the problem and the fix.
During the same timeframe today, there have been 1 stuck thread on
Tomcat A and 6 on Tomcat B.
That is great news.
If the numbers hold, this works out to roughly a 10,000% improvement.
Not bad for free support ;)
Seriously, I am glad that we seem to have tracked down the root cause
and that you have a temporary fix that works until such time (probably
the July releases) that we can figure out how we want to address caching
of "not found" classes.
Yeah... this doesn't seem like a great default policy for a few reasons:
1. Maybe the classes will appear in the future? JSPs? Plugins that
speculatively-load, then fail, then download/update, then try again? I'm
grasping at straws a little, here.
2. Huge numbers of cache misses will cause huge numbers of cached "not
found" entries. Potential DOS? I guess that would be an application bug
if it's allowing huge numbers of random class-loading requests. Again,
grasping at straws.
But my spidey-sense it tingling at this one.
Maybe (a) default-off option and (b) limit the total number of cached
"not found" items to something "smallish" like 100? 1000? 10000? Just
enough to not fill the heap if something goes terribly wrong.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
