You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by rb...@apache.org on 2001/11/10 22:07:13 UTC
cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
rbb 01/11/10 13:07:13
Modified: include http_connection.h
server connection.c
server/mpm/winnt mpm_winnt.c
Log:
Fix the Windows MPM. Windows doesn't always use the lingering close
function. If it can re-use the socket, we are better off not calling
the function. To fix this, we re-expose the lingering_close function,
and we allow the MPM to remove the cleanup.
Revision Changes Path
1.39 +16 -0 httpd-2.0/include/http_connection.h
Index: http_connection.h
===================================================================
RCS file: /home/cvs/httpd-2.0/include/http_connection.h,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- http_connection.h 2001/11/10 18:26:29 1.38
+++ http_connection.h 2001/11/10 21:07:13 1.39
@@ -88,6 +88,22 @@
AP_CORE_DECLARE(void) ap_flush_conn(conn_rec *c);
+/**
+ * This function is responsible for the following cases:
+ * <pre>
+ * we now proceed to read from the client until we get EOF, or until
+ * MAX_SECS_TO_LINGER has passed. the reasons for doing this are
+ * documented in a draft:
+ *
+ * http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-connection-00.txt
+ *
+ * in a nutshell -- if we don't make this effort we risk causing
+ * TCP RST packets to be sent which can tear down a connection before
+ * all the response data has been sent to the client.
+ * </pre>
+ * @param c The connection we are closing
+ */
+apr_status_t ap_lingering_close(void *dummy);
#endif
/* Hooks */
1.86 +1 -1 httpd-2.0/server/connection.c
Index: connection.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/connection.c,v
retrieving revision 1.85
retrieving revision 1.86
diff -u -r1.85 -r1.86
--- connection.c 2001/11/10 18:26:29 1.85
+++ connection.c 2001/11/10 21:07:13 1.86
@@ -149,7 +149,7 @@
* all the response data has been sent to the client.
*/
#define SECONDS_TO_LINGER 2
-static apr_status_t ap_lingering_close(void *dummy)
+apr_status_t ap_lingering_close(void *dummy)
{
char dummybuf[512];
apr_size_t nbytes = sizeof(dummybuf);
1.189 +3 -0 httpd-2.0/server/mpm/winnt/mpm_winnt.c
Index: mpm_winnt.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/mpm/winnt/mpm_winnt.c,v
retrieving revision 1.188
retrieving revision 1.189
diff -u -r1.188 -r1.189
--- mpm_winnt.c 2001/11/10 18:26:29 1.188
+++ mpm_winnt.c 2001/11/10 21:07:13 1.189
@@ -902,6 +902,9 @@
if (!disconnected) {
context->accept_socket = INVALID_SOCKET;
}
+ else {
+ apr_pool_cleanup_kill(context->ptrans, c, ap_lingering_close);
+ }
}
else {
/* ap_new_connection closes the socket on failure */
Re: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
Posted by Ryan Bloom <rb...@covalent.net>.
On Saturday 10 November 2001 04:33 pm, Jeff Trawick wrote:
> Ryan Bloom <rb...@covalent.net> writes:
> > On Saturday 10 November 2001 01:07 pm, rbb@apache.org wrote:
> > > rbb 01/11/10 13:07:13
> > >
> > > Modified: include http_connection.h
> > > server connection.c
> > > server/mpm/winnt mpm_winnt.c
> > > Log:
> > > Fix the Windows MPM. Windows doesn't always use the lingering close
> > > function. If it can re-use the socket, we are better off not calling
> > > the function. To fix this, we re-expose the lingering_close
> > > function, and we allow the MPM to remove the cleanup.
> >
> > Bill, can you make sure this fixes your problem? Long-term, this won't
> > work, but I want to keep the server working in the short-term. The
> > reason this won't work, is that you will never know if the
> > lingering-close function has been registered for any given connection.
> > We'll have to figure out how to fix that, but for now this will work.
>
> I liked somebody's (Greg Stein's??) idea recently where lingering
> close could be a hook or optional function which the MPM could
> implement (perhaps with a no-op). An MPM should be able to implement
> lingering close on its own. A single thread could be devoted to
> doing the lingering close.
>
> I'm not sure if the ability of an MPM to do this has changed
> recently. It seems weird to have to kill a cleanup in order to make
> it work.
The problem is that lingering close is tied VERY closely to the underlying
network mechanism. In fact, it only makes sense if you are dealing with
TCP directly. I can't see lingering close being useful with an SSL socket.
We can have the core implement the lingering_close thread, and have
two macros, MPM_WANTS_LINGERING_CLOSE and
MPM_WANTS_THREADED_LINGERING_CLOSE. This will allow the MPM
to override the core, while still allowing the core to implement lingering_close.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
Posted by Jeff Trawick <tr...@attglobal.net>.
Ryan Bloom <rb...@covalent.net> writes:
> On Saturday 10 November 2001 01:07 pm, rbb@apache.org wrote:
> > rbb 01/11/10 13:07:13
> >
> > Modified: include http_connection.h
> > server connection.c
> > server/mpm/winnt mpm_winnt.c
> > Log:
> > Fix the Windows MPM. Windows doesn't always use the lingering close
> > function. If it can re-use the socket, we are better off not calling
> > the function. To fix this, we re-expose the lingering_close function,
> > and we allow the MPM to remove the cleanup.
>
> Bill, can you make sure this fixes your problem? Long-term, this won't work,
> but I want to keep the server working in the short-term. The reason this won't
> work, is that you will never know if the lingering-close function has been
> registered for any given connection. We'll have to figure out how to fix that,
> but for now this will work.
I liked somebody's (Greg Stein's??) idea recently where lingering
close could be a hook or optional function which the MPM could
implement (perhaps with a no-op). An MPM should be able to implement
lingering close on its own. A single thread could be devoted to
doing the lingering close.
I'm not sure if the ability of an MPM to do this has changed
recently. It seems weird to have to kill a cleanup in order to make
it work.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
Posted by Ryan Bloom <rb...@covalent.net>.
On Saturday 10 November 2001 01:07 pm, rbb@apache.org wrote:
> rbb 01/11/10 13:07:13
>
> Modified: include http_connection.h
> server connection.c
> server/mpm/winnt mpm_winnt.c
> Log:
> Fix the Windows MPM. Windows doesn't always use the lingering close
> function. If it can re-use the socket, we are better off not calling
> the function. To fix this, we re-expose the lingering_close function,
> and we allow the MPM to remove the cleanup.
Bill, can you make sure this fixes your problem? Long-term, this won't work,
but I want to keep the server working in the short-term. The reason this won't
work, is that you will never know if the lingering-close function has been
registered for any given connection. We'll have to figure out how to fix that,
but for now this will work.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
Posted by Ryan Bloom <rb...@covalent.net>.
On Saturday 10 November 2001 01:07 pm, rbb@apache.org wrote:
> rbb 01/11/10 13:07:13
>
> Modified: include http_connection.h
> server connection.c
> server/mpm/winnt mpm_winnt.c
> Log:
> Fix the Windows MPM. Windows doesn't always use the lingering close
> function. If it can re-use the socket, we are better off not calling
> the function. To fix this, we re-expose the lingering_close function,
> and we allow the MPM to remove the cleanup.
Bill, can you make sure this fixes your problem? Long-term, this won't work,
but I want to keep the server working in the short-term. The reason this won't
work, is that you will never know if the lingering-close function has been
registered for any given connection. We'll have to figure out how to fix that,
but for now this will work.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------