> -----Original Message----- > From: Mark Thomas <ma...@apache.org> > Sent: Friday, May 31, 2024 11:45 AM > To: users@tomcat.apache.org > Subject: Re: Database Connection Requests Initiated but Not Sent on the Wire > (Some, Not All) > > 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. >
We verified application functionality during the wee hours and examined the logs for evidence of any new issues that may have been introduced by the patch. I thought about deploying it to just one server but decided such a test would be inconclusive, as we could only know if it really works by allowing it to be stress-tested. I had a gut feeling it would be okay. 😊 > > 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 ;) > The best! > 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. > We're eager to see how you address it permanently. In the meantime, we're delighted because the vendor's recommended "solution" would have been to triple the number of tomcat instances, which turns into a maintenance and troubleshooting headache. I would bet they have had other cases of slowness where the root cause was not isolated. This is a win-win, as it helps both us and them. > Cheers, > Cheers back! > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Disclaimer : This email and any files transmitted with it are confidential and intended solely for intended recipients. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physician Select Management. Warning: Although Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
