(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
URL: https://issues.apache.org/jira/browse/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 future.
*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 session.
*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 CLOSE_WAIT.
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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
