Hi! Christopher Schultz.
​
Thank you for your reply.
​
1. KeepAliveTimeout is not set but connectionTimeout = "15000", so 
keepAliveTimeout is automatically set to 15 seconds?
​
https://tomcat.apache.org/tomcat-8.0-doc/config/ajp.html
​
keepAliveTimeout        
The number of milliseconds this Connector will wait for another AJP request 
before closing the connection. The default value is to use the value that has 
been set for the connectionTimeout attribute.
​
​
2. I will run Tomcat 7 on Java 8 and make sure that thread state matches what I 
see on Tomcat 8 in Java 8.

Best regards.

-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net> 
Sent: Saturday, March 31, 2018 2:23 AM
To: users@tomcat.apache.org
Subject: Re: Is the thread status of tomcat 8.0.44 normal?

-----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





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to