On 5/31/2024 11:44 AM, 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.
Cheers,
Mark
Kudos!
Would this mean that a "not found" class would be forever "not found"
until a restart? How does Tomcat handle jars or classes added or removed
while it's running now? Could a class be removed from the "not found"
cache if a change was detected? Would it be worth maintaining a list of
all available classes?
Really well done!
-Terence
