You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Wendell L. Hatcher (Created) (JIRA)" <ji...@apache.org> on 2011/10/13 00:43:11 UTC
[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.
(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
[jira] [Resolved] (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.
Posted by "Emmanuel Bourg (Resolved) (JIRA)" <ji...@apache.org>.
[ 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