You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2011/09/14 22:49:53 UTC
DO NOT REPLY [Bug 51814] New: 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.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51814
Bug #: 51814
Summary: 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.
Product: Apache httpd-2
Version: 2.2.20
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_proxy
AssignedTo: bugs@httpd.apache.org
ReportedBy: wendell_hatcher@comcast.net
Classification: Unclassified
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 51814] 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 bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51814
Eric Covener <co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #2 from Eric Covener <co...@gmail.com> ---
NEEDINFO = info needed from originator
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 51814] 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 bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51814
sebmoule <se...@orange.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #1 from sebmoule <se...@orange.com> ---
Hello, Is there any news about this bug ?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 51814] 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 bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51814
Eric Covener <co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
--- Comment #3 from Eric Covener <co...@gmail.com> ---
I'm reclassifying this an enhancement -- check for closed idle connections in
the pool more frequently or asynchronously. The fact that they may sit in a
closed state before being noticed is not itself a defect IMO.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 51814] 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 bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51814
sebmoule <se...@orange.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sebastien.allamand@orange.c
| |om
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org