You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by el...@apache.org on 2018/01/07 14:39:48 UTC
svn commit: r1820466 - /httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml
Author: elukey
Date: Sun Jan 7 14:39:47 2018
New Revision: 1820466
URL: http://svn.apache.org/viewvc?rev=1820466&view=rev
Log:
event.xml: add a note about lingering close
Modified:
httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml
Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml?rev=1820466&r1=1820465&r2=1820466&view=diff
==============================================================================
--- httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml Sun Jan 7 14:39:47 2018
@@ -94,7 +94,9 @@ of the <directive>AsyncRequestWorkerFact
sockets and they can be re-used to serve other requests.</dd>
<dt>Closing</dt>
- <dd>Sometimes the MPM needs to perform a lingering close, namely sending back an early error to the client while it is still transmitting data to httpd. Sending the response and then closing the connection immediately is not the correct thing to do since the client (still trying to send the rest of the request) would get a connection reset and could not read the httpd's response. So in such cases, httpd tries to read the rest of the request to allow the client to consume the response. The lingering close is time bounded but it can take relatively long time, so a worker thread can offload this work to the listener.</dd>
+ <dd>Sometimes the MPM needs to perform a lingering close, namely sending back an early error to the client while it is still transmitting data to httpd. Sending the response and then closing the connection immediately is not the correct thing to do since the client (still trying to send the rest of the request) would get a connection reset and could not read the httpd's response. So in such cases, httpd tries to read the rest of the request to allow the client to consume the response. The lingering close is time bounded but it can take relatively long time, so a worker thread can offload this work to the listener. From 2.4.28 onward
+ the listener does not perform the lingering close anymore but it offloads the job to the first worker available.
+ </dd>
</dl>
<p>These improvements are valid for both HTTP/HTTPS connections.</p>
Re: svn commit: r1820466 - /httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml
Posted by Luca Toscano <to...@gmail.com>.
Hi Yann,
2018-01-07 20:41 GMT+01:00 Yann Ylavic <yl...@gmail.com>:
> Hi Luca,
>
> On Sun, Jan 7, 2018 at 3:39 PM, <el...@apache.org> wrote:
> > Author: elukey
> > Date: Sun Jan 7 14:39:47 2018
> > New Revision: 1820466
> >
> > URL: http://svn.apache.org/viewvc?rev=1820466&view=rev
> > Log:
> > event.xml: add a note about lingering close
> >
> > Modified:
> > httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml
> >
> > Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml
> > URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/
> docs/manual/mod/event.xml?rev=1820466&r1=1820465&r2=1820466&view=diff
> > ============================================================
> ==================
> > --- httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml (original)
> > +++ httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml Sun Jan 7
> 14:39:47 2018
> > @@ -94,7 +94,9 @@ of the <directive>AsyncRequestWorkerFact
> > sockets and they can be re-used to serve other
> requests.</dd>
> >
> > <dt>Closing</dt>
> > + [...] The lingering close is time bounded but it can take
> relatively long time, so a worker thread can offload this work to the
> listener. From 2.4.28 onward
> > + the listener does not perform the lingering close anymore
> but it offloads the job to the first worker available.
>
> We can probably join these two sentences (moreover both are quite
> contradictory, the lingering close is really offloaded *by* the
> listener *to* a worker.
>
This is my fault, I was convinced that the worker was delegating the
lingering close to the listener entirely, not only when the connection
timeout elapsed. This is why I wrote from the worker to the listener and
not the other way around.
>
> So how about something like:
> "The lingering close is time bounded but it can take relatively long
> time, so it's offloaded to a worker thread (including the shutdown
> hooks and real socket close), and from 2.4.28 onward this is also the
> case when connections finally timeout (the listener thread never
> handles connections besides waiting for and dispatching their
> events)."
> ?
>
Committed in trunk/2.4.x with a small variation (added a . to separate the
two sentences).
Thanks a lot for the explanation, sorry for the wrong docs :)
Luca
Re: svn commit: r1820466 - /httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml
Posted by Yann Ylavic <yl...@gmail.com>.
Hi Luca,
On Sun, Jan 7, 2018 at 3:39 PM, <el...@apache.org> wrote:
> Author: elukey
> Date: Sun Jan 7 14:39:47 2018
> New Revision: 1820466
>
> URL: http://svn.apache.org/viewvc?rev=1820466&view=rev
> Log:
> event.xml: add a note about lingering close
>
> Modified:
> httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml
>
> Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml
> URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml?rev=1820466&r1=1820465&r2=1820466&view=diff
> ==============================================================================
> --- httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml (original)
> +++ httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml Sun Jan 7 14:39:47 2018
> @@ -94,7 +94,9 @@ of the <directive>AsyncRequestWorkerFact
> sockets and they can be re-used to serve other requests.</dd>
>
> <dt>Closing</dt>
> + [...] The lingering close is time bounded but it can take relatively long time, so a worker thread can offload this work to the listener. From 2.4.28 onward
> + the listener does not perform the lingering close anymore but it offloads the job to the first worker available.
We can probably join these two sentences (moreover both are quite
contradictory, the lingering close is really offloaded *by* the
listener *to* a worker.
So how about something like:
"The lingering close is time bounded but it can take relatively long
time, so it's offloaded to a worker thread (including the shutdown
hooks and real socket close), and from 2.4.28 onward this is also the
case when connections finally timeout (the listener thread never
handles connections besides waiting for and dispatching their
events)."
?
Thanks for taking care of event's docs!
Regards,
Yann.