-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 이의준,
On 3/29/18 9:05 PM, 이의준 wrote: > Thank you, Mr. Christopher Schultz. > > If the keepalivetimeout value is the same, it is not the > difference between tomcat7 and tomcat8 eventually, it is the Thread > state corresponding to the inflowing request situation, so is > normal operation? > > What Java versions in each case? > > --> Tomcat 7 : jdk 1.7.0.65 --> Tomcat 8 : jdk 1.8.0.131 > > All settings are the same. If the stack traces are (roughly) the same, then what you are seeing is the difference in opinion between Java 7 and Java 8 about what the "state" of a thread is. Run Tomcat 7 on Java 8 and see if the thread-states agree with what you see with Tomcat 8 on Java 8. I misspoke earlier. There is no keep alive timeout for an AJP connector. AJP connections are expected to remain connected for a long time, proxying many requests during that time. Any threads in the "read" state are simply waiting for the next request to come from the reverse proxy (httpd). Any that are not in the "read" state simply haven't been used, yet. > #httpd.conf fragment on apache http server connected to Tomcat 7. > > KeepAlive On KeepAliveTimeout 30 MaxKeepAliveRequests 0 Timeout 60 Not relevant. (Well...) > #Tomcat 7 server.xml fragment <!-- Define an AJP 1.3 Connector on > port 8009 --> <Connector port="7009" protocol="AJP/1.3" > redirectPort="9443" URIEncoding="UTF-8" acceptCount="200" > acceptorThreadCount="2" maxThreads="300" minSpareThreads="50" > connectionTimeout="15000"/> > #Tomcat 8 server.xml fragment <!-- Define an AJP 1.3 Connector on > port 8009 --> <Connector port="7009" protocol="AJP/1.3" > redirectPort="9443" URIEncoding="UTF-8" acceptCount="200" > acceptorThreadCount="2" maxThreads="300" minSpareThreads="50" > connectionTimeout="15000"/> It's also worth mentioning whether or not you are using the native connector (AJP/APR) or an all-Java connector (AJP/BIO, AJP/NIO). From the stack traces, we can see that you are using AJP/APR in both cases. Java can't get a good thread-state (e.g. WAITING) from those native threads because the blocking is happening at the native/OS level and the JVM can't see that, so it things the thread is "running". Don't worry, it's actually blocked and (probably) using zero CPU. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlq+cn8ACgkQHPApP6U8 pFiW+Q/+IfCVzYf3LAzRC2PvmPUSWYPL9y7Q0z8ldWeYWVr9q91ceTXb53CsGZKN G2UAw0ISMrqCpzRlfAAWuwcg+FDKB8LNhNDy0zmn1gArIc3zMW4bLegGtd1LFm5L 0FwHGhgUpQXhy7Iz18ALYdr3DrDhlr++3CmxnS1vZtWCI8+0ROwqP+ZnTwB5fedN mbUDSATU+VtPb489OWxaQjNkJf9cQOM4tC3IIgsdcvbcbDeLR0wfkgW112L9Xjdw AA7JEYkxoi6dpb6yQu0rCFShizK7WirRua7v3RMi/8fZcmT30weD2xbuol6hb5oi EQFUlEnFGw7ZNi8rMs0sYdKd+u8U9twIKzWEzfwBzH7rPhaC1TcrWQCDL8y70qOL 8qVyLYLuJQrU28vv4uSFhj7OYS3a7HzjWRKoQKwBhtpKm3yb+Tw6qqkuXaAuYNpR eI86lI6mpjMQgEOEUcluMTpMMcgXf7P9rX03qImpEkjEZsmG4ZmGB7Nqe5fuIGAF 7KXvoCtJ+UD6AYh5zcgcu8LhaO9NFXWLALQvw+x+1K4K9nIiGBudezWP1cwmxes6 0iWt718EHuy5N67h7DW1rlPh3+y1upCtQ7RCcaFFDgjMGiOOBbeDAHNiZDfN7BvV 4Im0UadVKFEjW+2MaRu2/N+KsvWAO6peK+Z8iPcLqgRlPnZmnz8= =0qpW -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
