commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wendell L. Hatcher (Created) (JIRA)" <>
Subject [jira] [Created] (PROXY-16) (PROXY-15) mod_proxy in Apache HTTP 2.2 FIN_WAIT2 in server side, it leaves as CLOSE_WAIT for a long time in mod_proxy side.
Date Wed, 12 Oct 2011 22:43:11 GMT
(PROXY-15) mod_proxy in Apache HTTP 2.2 FIN_WAIT2 in server side, it leaves as CLOSE_WAIT for
a long time in mod_proxy side.

                 Key: PROXY-16
             Project: Commons Proxy
          Issue Type: Bug
            Reporter: Wendell L. Hatcher

if mod_proxy, but during being FIN_WAIT2 in server side, it leaves as CLOSE_WAIT for a long
time in mod_proxy side.

This might be only a small bad effect for this phenomenon, but we think this occurs because
of not preferred implementation of Apache httpd mod_proxy.
Specifically, mod_prxoy sends FIN by KeepAliveTimeout from backend server side. When it gets
it, it returns using FIN and ACK, then wants to release ports that is in use.

This is because of the following reasons:
*Keeping unnecessary resource for a long time, this might occur some unexpected bugs in the
*If CLOSE_WAIT condition continues for a long time and then there is Firewall between mod_proxy_http
and backend, then you have to keep unnecessary session and this might affect communication
*If there is FIN and ACK that after there is a long time gap, then it would already be after
Firewall destroys that session and Firewall might show warning messages.

Also in mod_proxy in Apache 2.0, if client doesn't use KeepAlive, the connection between mod_proxy
and backend server ends, and confirms that CLOSE_WAIT doesn't stays. In short, Apache 2.2
doesn't behave good than Apache 2.0.
When we compare Apache 2.2 and 2.0 source, in Apache 2.0 mod_proxy, client side TCP session
extension of the ending process, it closes TCP session between backend server using apr_socket_close()
function. However, in Apache 2.2 mod_proxy_http, it changes as to call connection_clceanup()
or socket_cleanup(), and we thiknk this is because it doesn't do apr_socket_close() in the
function. In short, 2.2 doesn't close the session that is immediately close when KeepAlive
is invalid. We assume that this is a simple bug that forgets to close when mod_proxy's refactoring.

(1) Client is HTTP/1.0 and KeepAlive is none, so every time the connection ends by FIN.

(2) mod_proxy_http doesn't disconnect after receiving the result of backend server request.

(3) Backend server though FIN at 30.007sec by KeepAliveTimeout. mod_proxy_http doesn't return
FIN for this.

Port 47875 of mod_proxy_http becomes CLOSE_WAIT after this.
(4) New request reaches mod_proxy_http at 41.547sec and creating a different new TCP section
at 41.546sec. This is also throwing FIN and then disconnecting it, but it's NOT disconnecting
in the backend server side. However, it's disconnecting from backend server side at 71,545,
but mod_proxy_http doesn't return FIN. After this, Port 47486 of mod_proxy_http becomes CLOSE_WAI.T

(5) Client throws a new request to mod_proxy_http at 77.157sec. At this time, at 77.159sec,
mod_proxy_http thows FIN and ACK from the above # (3), port 47485, then the first time that
(3) session ends here. It took 47 seconds until here, and if we compare it with KeepAliveTimeout
that is set at the backend server, there is a big gap.

We have done it a few times and found out the following:
a) mod_proxy_http uses KeepAlive between backend, although client doesn't use KeepAlive.

b) Even if Backend send FIN by KeepAliveTimeout, mod_proxy_http doesn't response and become

c) mod_proxy_http becomes CLOSE_WAIT when a new request recives.

d) However, if a new request doesn't come then it never sends FIN to an old connection and
stays as CLOSE_WAIT forever.

We assume that b) and d) are not good behaviors for TCP/IP connections. Already connection
to client is disconnected; it doesn't depend on client's KeepAlive behavior.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message