Hi.
I am not the one who can really answer your question, but
1) this is the right list for Apache/Tomcat connectors (mod_jk among them)
2) a question : do these CLOSE_WAIT sockets bother you for some specific reason
?
In a totally different context, I have had problems with Linux systems when hundreds of
such sockets accumulated over time (entire TCP stack becoming unresponsive at some point),
but they do not seem to have an impact when the number remains "reasonable" (below one
hundred or so).
In this case, as I understand things, there will be a maximum of N such sockets, where N
is the maximum number of threads which Tomcat may have, at some point, running
simultaneously from this AJP Connector. (And it is also the number of connections which
mod_jk will automatically configure in its pool).
On many of the sites which I take care of, I regularly see 25-50 such mod_jk sockets in
CLOSE_WAIT state for extended periods of time, and they do not seem to have any negative
consequences on the system. They just clutter the netstat displays, but you can always
"grep -v" them out.
Edward Quick wrote:
Hi,
Apologies in advance if this is the wrong mailing list. I was unable to find
one specific to mod_jk and this looked the most relevant.
I have the following apache tomcat server configuration set up: Apache 2.2.3 ,
mod_jk 1.2.32 , and tomcat 6.0.32 running HelloWorld.war
If I send a request to http://remotehost/HelloWorld/index.jsp, I observe the
following behaviour:
1 ) My tomcat AJP connector is listening on port 8010
TEST [root@remotehost]$ netstat -an | grep 8010
tcp 0 0 0.0.0.0:8010 0.0.0.0:*
LISTEN
2) I make a request to http://remotehost/HelloWorld/index.jsp and see the
apache establish a connection to tomcat. The response comes back straightaway.
TEST [root@remotehost]$ netstat -an | grep 8010
tcp 0 0 0.0.0.0:8010 0.0.0.0:*
LISTEN
tcp 0 0 10.34.2.140:8010 10.34.2.140:46792
ESTABLISHED
tcp 0 0 10.34.2.140:46792 10.34.2.140:8010
ESTABLISHED
3) After reaching KeepAliveTimeout on the Tomcat AJP connector, the connections
change state:
TEST [root@ remotehost]$ netstat -an | grep 8010
tcp 0 0 0.0.0.0:8010 0.0.0.0:*
LISTEN
tcp 0 0 10.34.2.140:8010 10.34.2.140:46792
FIN_WAIT2
tcp 1 0 10.34.2.140:46792 10.34.2.140:8010
CLOSE_WAIT
4) After about another minute, the FIN_WAIT2 is cleared, but the CLOSE_WAIT
remains (on the apache) until reaching net.ipv4.tcp_keepalive_time (which is
set to 7200 seconds)
TEST [root@ remotehost]$ netstat -an | grep 8010
tcp 0 0 0.0.0.0:8010 0.0.0.0:*
LISTEN
tcp 1 0 10.34.2.140:46792 10.34.2.140:8010
CLOSE_WAIT
Everything there looks fine except for the CLOSE_WAIT which lingers around for
2 hours until it hits tcp_keepalive_time.
Adding JkOptions +DisableReuse will prevent the CLOSE_WAITs staying, but that
is also said to have a performance impact.
My question is if this is the expected tcpip state after the thread has
finished, because in JDBC I see the connections permanently ESTABLISHED or in
TIME_WAIT.
Thanks for any help.
Ed.
________________________________
The information contained in this email is strictly confidential and for the
use of the addressee only, unless otherwise indicated. If you are not the
intended recipient, please do not read, copy, use or disclose to others this
message or any attachment. Please also notify the sender by replying to this
email or by telephone (+44 (0)20 7896 0011) and then delete the email and any
copies of it. Opinions, conclusions (etc) that do not relate to the official
business of this company shall be understood as neither given nor endorsed by
it. IG Group Holdings plc is a company registered in England and Wales under
number 01190902. VAT registration number 761 2978 07. Registered Office: Cannon
Bridge House, 25 Dowgate Hill, London EC4R 2YA. Authorised and regulated by the
Financial Services Authority. FSA Register number 114059.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
