-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Raghav,
On 4/30/20 03:02, Ragavendhiran Bhiman (rabhiman) wrote: > Hello Chris, > > Please see my reply below in line. > > Thanks & Regards, > > Raghav > > On 30/04/20, 9:23 AM, "Christopher Schultz" <ch...@christopherschultz.net> wrote: > > Raghav, > > On 4/29/20 22:26, Ragavendhiran Bhiman (rabhiman) wrote: >> The below is the executer element. > >> <Executor name="AdminExecutorPool" namePrefix="admin-http-pool" >> maxThreads="450" minSpareThreads="5"/> > >> I also captured the network pcap and able to see many RST >> packets in between that is marked as RED in wireshark. > > Okay, so far you have told us: > > 1. You are using Tomcat 8.5.29 >> [Raghav] yes correct. > 2. You have an <Executor> with 450 threads in it >> [Raghav] Executor has 450 threads. > > 3. You see "lots of threads" >> [Raghav] Yes above 450 threads or all the. 450 threads are alive. >> How many more than 450? Or are you only concerned that all 450 threads are in use when you think they should not be? > 4. You are seeing lots of RST packets. >> [Raghav]I can provide one snapshot of pcap analyisis after the >> application data exchange only I am able to see the RST packet >> which I see could be ok or sent for socket closing. RST packets in and of themselves aren't cause for alarm. > We can't help you without more details. Pretend we aren't looking > at your screen as you investigate. > > How many threads are you seeing? More than 450? How many, exactly? > What are the names of the threads? > >> [Raghav] Yes all the 450 threads are alive. Okay, what's the problem? > Some things I have noticed that seem ... suspicious. > > 1. Your sslImplementationName is invalid. >> [Raghav] is the SSL implementation name has to be changed? What >> is the SSL name to be used? Usually it doesn't need to be specified. Sometimes, it makes sense to override the default. But you have overridden the default with a class that does not exist in Tomcat. I'm not sure what Tomcat will do if the class is invalid. Or maybe your developers have patched Tomcat to include a new SSLImplementation class? That would make sense if (a) you have an odd-looking sslImplementationName configuration setting and (b) your I/O channels are behaving strangely (because you have a broken I/O implementation). > 2. You have a 5-minute keepAliveTimeout -- which sounds insanely > high -- and an infinite number of keepalive requests. Are you > fronting Tomcat with a load-balancer or other reverse-proxy? >> [Raghav]. Yes, 5 minutes timeout is high. I already informed to >> the team. But people are saying previous versions are working >> properly where the large number of threads are not there. Okay, but this is still probably not a good idea. Are you indeed using a load-balancer? If you are, then having a long keep-alive timeout is actually a *good* thing, because it will improve performance between the lb and Tomcat. But no individual real-world client needs a 5-minute keep-alive timeout. >> I think the threads are based on the number of requests is it >> true? It's complicated. Usually, your thread pool will contain the number of threads equal to the high-water-mark of the number of simultaneous request (plus or minus a few, depending on timing). If it's not configured correctly, those threads will never be released. Whether or not that's a Bad Thing in your environment is up to you. > 3. You have sendReasonPhrase="true" which indicates that you are > working with clients which violate the HTTP specification. >> [Raghav] this doesn't matter. I don’t know how this has been set >> to true. > > 4. You have an infinite "maxSavePostSize" setting. Are you > expecting many users to perform unauthenticated POSTs where the > POST body needs to be very large, and saved-and-replayed during the > authentication step? >> [Raghav] This is not known. > > 5. Your keystoreType is PKCS11 which is usually a hardware > keystore. Fine. But you have a truststoreType of PKCS11 as well. > Are you using a hardware trust store as well? >> [Raghav] Not sure about this. There are many ciphers defined >> along with this as well. The ciphers are about communication with the client. The keystore is about getting the crypto started. The trust store is about trusting clients connecting to you. If you aren't using client TLS certificates, then you shouldn't have a trust store configured at all. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6rMgkACgkQHPApP6U8 pFgDGRAAwpdgRhpTzSvXZQJurphNFBPHdmdXbq05gm6bdKpRcViMCU9J1SWQhAZU tO5md6T0EvWDIhr8jRfnAkH/9f1U5iF1dzIncdOjspJAfbkt0mUVd6ARbWr/NPLl iE78SbZx3H4h2PuQJ0jhWdEToEz8p3bxzSP6v2/fUM3J+2zRLfB8NzNRTjIllQPy Jt06eR/jVY70Vf0aSgNKVX1bY5rdVjtA0YIGLatPvpqIkzQNi9RH0Scd4rLZoZl7 4OaLNbYmV47at4TJ0iqpND9DDWvd6fFK9j69ju/CDQHrBXctarpofbu8Tg235UIz 5hZuMer4yg3fs87+XOPLhgyDHeXuzM49GljRtaelfPhxM59Nq11in60DYfITrWEp YwyvTkptbLLXglFhRvRzx2kFvVQSTpK4I9LJMp3z/7uAeo364K2iQW06XB6VU6CG yeBSR0UkhghzckfWX3vFD5dyus+s7sL/x7MKRait2MPePm76JjLFk93CmZnnQWr4 kqbNDeYVacADVGtwe3Xsp5rdUm/tW4HVrtcA1IsHPQtqnKKrCI0qFdXjIs5bkFqh 9aMFKSFrMRXAh1jaIIzuALSmuA8H6YUFDhtUwXBdYr5KthupuZfQkUxvKtaYNbLJ XUAOE/VZpvN3PTc4l7A+f3SEUCD8EGUPZKKh31WCd+ZSMXt+poA= =r+/6 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
