I have just updated to the latest Tomcat 9.0.41 It seems that the problem doesn't appear anymore. If I get it reappeared, I'll post new details to the Tomcat dev mailing list.
On Thu, Dec 17, 2020 at 8:56 AM Mladen Adamović <mladen.adamo...@gmail.com> wrote: > I have these problems again. To narrow it down I have done the following: > - tested with the latest JDK8 - problem exists > - it exists in both Apr connector and Nio2 connector > - did log JVM Garbage Collector details - it's not due to Garbage collector > > Christopher (or anyone else), if we had 1570 requests per minute where > this problem happened (approx. 26 per second), what do you think should our > Connector params be, it's currently: > > <Connector port="8181" > protocol="org.apache.coyote.http11.Http11Nio2Protocol" > SSLCertificateFile="/etc/letsencrypt/live/ > numbeo.com/cert.pem" > SSLCertificateKeyFile="/etc/letsencrypt/live/ > numbeo.com/privkey.pem" > SSLCertificateChainFile="/etc/letsencrypt/live/ > numbeo.com/chain.pem" > SSLVerifyClient="optional" > SSLProtocol="TLSv1+TLSv1.1+TLSv1.2" > connectionTimeout="20000" acceptCount="30000" > acceptorThreadCount="4" > compression="on" maxConnections="50000" maxThreads="500" > > compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,image/svg+xml,image/svg,image/png,image/jpeg" > > useSendfile="false" > maxHttpHeaderSize="16392" SSLEnabled="true" > enableLookups="false" > scheme="https" secure="true" clientAuth="false" > useBodyEncodingForURI="true" > URIEncoding="UTF-8" > /> > > > > > > On Wed, Dec 16, 2020 at 7:32 PM Mladen Adamović <mladen.adamo...@gmail.com> > wrote: > >> On Wed, Dec 16, 2020 at 7:07 PM Christopher Schultz < >> ch...@christopherschultz.net> wrote: >> >>> I think your scripts will restart Tomcat even when it's not necessary. >>> >> >> Hm, is this >> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates >> the way to reload the certificates or is there another suggestion? >> >> >>> The $? check before sending the email message looks like it should be >>> checking the result of the certbot command, but it's checking the result >>> of the chmod command instead. (Or maybe the result of the .sh script, >>> which will proably be 0.) >>> >> >> Correct, thank you this is fixed now. >> >> >>> I might have found that odd had you posted that in your original >>> message, but you did not. >>> >>> You need to show the full stack trace for that thread to make it >>> meaningful. Sockets are added to the poller all the time. It's not >>> unusual to see that happening. It they are getting *stuck*, that would >>> be bad, of course. >>> >> >> I did post full thread dump. >> >> >>> > Don't you find it weird that all threads are trying to get >>> synchronized >>> > on a Poller instance and no one is in this block or another >>> synchronized >>> > block/method? >>> >>> I would find it weird if no threads were making any progress. Lots of >>> threads adding sockets to the poller is not out of the ordinary. >>> >>> If you suspect a bug in Tomcat's socket handling, upgrading to the >>> latest 8.5.x release and re-trying would be the best move. There have >>> been many fixes since your 8.5.5 release which is now 4+ years old. >>> >> >> I have switched today from Apr connector to Nio2 connector and no >> problem yet. >> What I have found strange is that processor usage is lower when using >> Nio2, I have never tested it or tried it before, I have setup APR for >> performances reason back in 2016. But oddly it seems with Nio2 processor >> usage is lower. >> I have tried the last OpenJDK but jstack is not working for me, so >> switched back to the previous old JRM. >> Let's see what will happen... >> >> >> >> >>> -chris >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>>
