Chris, maxThreads has been set after reviewing the workload. We used a multiple of 64.
The connections are from bots and are unlikely to be pipelined. Connections can be bursty - hence, a bigger acceptCount. Will revert to 10.0 and see. Regards, John -----Original Message----- From: Christopher Schultz <ch...@christopherschultz.net> Sent: Monday, September 30, 2024 5:39 PM To: users@tomcat.apache.org Subject: Re: Tomcat 10.1.30 and Many Timed Waiting threads [You don't often get email from ch...@christopherschultz.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. John, On 9/30/24 13:34, John Williams wrote: > No - I cannot see any other thread stuck on DB/external resources. The > application functions as expected, just that I see these threads increasing > over time. > The problem was 1st noticed in Tomcat 10.1.26/OpenJRE 17.0.5 and I've tried > moving to Tomcat 10.1.30/OpenJRE 17.0.12 with no change. If you go back to 10.0 does it still behave as expected? You have a bit of a weird setup IMHO. > <Connector [...] > maxThreads="1536" This is a very strange number. Why not 1537? > minSpareThreads="64" This seems reasonable, but also kind of low given: > acceptCount="12000" So you are willing to accept HUGE numbers of connections and then let them sit in the TCP/IP stack's accept queue waiting for a processing thread. Why? > connectionTimeout="60000" Ouch. So you will accept huge numbers of connections and then allow them to sit there not making any request? This seems like a recipe for disaster. > socket.rxBufSize="131072" > socket.txBufSize="131072" Tweaking the socket buffer sizes is either an indication of an insanely well-tuned performance setup or that you don't know what you are doing. Given the other settings, I'm inclined toward the latter. > maxKeepAliveRequests="1" Disabling pipelining? Definitely not expecting a high performance service, or you are very sure that no client will ever make more than one request. > maxConnections="1536" You don't want this, especially for NIO. There is no reason to reduce this from the default, although your other settings make the non-blocking nature of the NIO connector moot (e.g. pipelining is disabled). Why do you have this collection of odd settings? -chris > -----Original Message----- > From: Chuck Caldarale <n82...@gmail.com> > Sent: Monday, September 30, 2024 1:26 PM > To: Tomcat Users List <users@tomcat.apache.org> > Subject: Re: Tomcat 10.1.30 and Many Timed Waiting threads > > [You don't often get email from n82...@gmail.com. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > >> On Sep 30, 2024, at 12:15, John Williams >> <john.willi...@eginnovations.com.INVALID> wrote: >> >> I had an executor defined before and it had the exact same behavior/problem. >> Moved to the below model for the connector only after that. > > > The OP didn't mention the real problem in his original message; it only > showed up as almost an afterthought in the second posting with the unusable > attachments: > > "Once it reaches close to the maxThreads setting we see connection drops." > > I wonder if there's something else blocking the application, such as stuck DB > operations or other delayed access to an external resource. > > - Chuck > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
