[
https://issues.apache.org/jira/browse/PROXY-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg resolved PROXY-16.
---------------------------------
Resolution: Invalid
Still not the right place for this report ;) Please see :
http://httpd.apache.org/bug_report.html
> (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
