Chris, > -----Original Message----- > From: Christopher Schultz <ch...@christopherschultz.net> > Sent: Friday, May 31, 2024 12:50 PM > To: users@tomcat.apache.org > Subject: Re: Database Connection Requests Initiated but Not Sent on the Wire > (Some, Not All) > > Eric, > > On 5/31/24 13:44, Eric Robinson wrote: > >> -----Original Message----- > >> From: Christopher Schultz <ch...@christopherschultz.net> > >> Sent: Friday, May 31, 2024 12:38 PM > >> To: users@tomcat.apache.org > >> Subject: Re: Database Connection Requests Initiated but Not Sent on > >> the Wire (Some, Not All) > >> > >> 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. > >> > > > > Would it, though? I don't know what a negative cache entry would look like, > but it seems to me that it would not have to create duplicates. > > I was thinking of cache entries for large numbers of different classes, all of > which were "not found". Not one class being requested over and over again. > It's > just lots of String keys in a hash map or whatever. Not horrific, but can get > out > of control of Something Goes Wrong. >
Gotcha. In that case, if there were hundreds of different classes not found, then it seems the app must have bigger problems, like entirely missing lib folders or something, and the system would barely function, if at all. I realize I'm speaking largely from ignorance here. > -chris > > --------------------------------------------------------------------- > 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
