Home / server / Questions / 594609
In Process
Ryan
Asked: 2014-05-13 10:39:43 +0800 CST

Apache Reverse Proxy Java Application Server CLOSE_WAIT Connections

  • 772

I've got Apache setup as a reverse proxy for a Java Application server (GlassFish) and I noticed there are about 100 connections in the state CLOSE_WAIT even on an idle development system:

sudo netstat -n -e -p -a -t | grep httpd | grep CLOSE_WAIT | wc -l

I'm using the following HTTP proxy settings:

ProxyPass /myapp http://localhost:8080/myapp ttl=20 max=1 smax=0
ProxyPassReverse /myapp http://localhost:8080/myapp

Why are all of these connections hanging around? I've set the "ttl=20 max=1 smax=0" so I figured all connections would be cleaned up on an idle system. Is the application server not doing its part to cleanup the connections?

apache-2.2

3 Answers

  1. This is a known issue with mod_proxy, since 2011.

    The ttl needs to be shorter than the application's keepalive, so that apache is always first to send a FIN.

    Another difficulty is it's not defined at what point the connection will actually be closed.

    ttl - Time to live for inactive connections and associated connection pool entries, in seconds. Once reaching this limit, a connection will not be used again; it will be closed at some later time.

    • 4

  2. I encountered similar issue and I am looking for reasoning with respect to Apache. I suspect Apache's prefork.

    As for the solution, I used Nginx that solved CLOSE_WAIT issue. However the number of TIME_WAIT (20,000 approx.) shows there is something not right with the way the Java application(s) handles connections. With Nginx server and application performs much better.

    I hope some one can improve this answer with technical depth.

    • 0

  3. These CLOSE_WAIT connections are dead, it is just the server keeping them in the tcp stack in case further packets get to them. In the "good old days", Solaris servers would run out of file descriptors if this was too big, and the system would crash. We had to increase the number of total file descriptors allowed in the kernel, and reduce the cleanup interval of CLOSE_WAIT connections.

    Now a days, the default number of file descriptors is usually large enough to ignore this. But the cleanup configuration can be reduced, so the number of CLOSE_WAIT connections will be reduced.

    It is by the very nature of these (Glassfish, Tomcat, JBoss, ...) to use a "large" number of connections and not reuse them. You can safely ignore, in most cases.

    • 0