You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Eric Covener <co...@gmail.com> on 2013/08/24 20:19:15 UTC
Re: svn commit: r1137358 - in /httpd/httpd/trunk: CHANGES
include/ap_mmn.h include/http_connection.h include/httpd.h
include/scoreboard.h server/connection.c server/mpm/event/event.c
server/mpm/event/fdqueue.c server/mpm/event/fdqueue.h
On Sun, Jun 19, 2011 at 8:23 AM, <sf...@apache.org> wrote:
> Author: sf
> Date: Sun Jun 19 12:23:42 2011
> New Revision: 1137358
>
> URL: http://svn.apache.org/viewvc?rev=1137358&view=rev
> Log:
> Some improvements for handling of many connections for MPM event:
>
> - Process lingering close asynchronously instead of tying up worker threads
> (based on patch by Jeff Trawick).
>
> + /* socket is already in non-blocking state */
> + do {
> + nbytes = sizeof(dummybuf);
> + rv = apr_socket_recv(csd, dummybuf, &nbytes);
> + } while (rv == APR_SUCCESS);
> +
> + if (!APR_STATUS_IS_EOF(rv)) {
> + return;
> + }
> +
> + rv = apr_pollset_remove(event_pollset, pfd);
> + AP_DEBUG_ASSERT(rv == APR_SUCCESS);
I was looking at an issue in this area, it seems like the
corresponding code in ap_lingering_close is not so picky about
apr_socket_recv return code. It seems like we could continually get
ECONNABORTED/ECONNRESET back and not take the socket out of the ring
until the timeout elapses.
I'm wondering if the test should be APR_STATUS_IS_EAGAIN(), and
anything else that isn't success means we no longer need to linger?
Re: svn commit: r1137358 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_connection.h include/httpd.h include/scoreboard.h server/connection.c server/mpm/event/event.c server/mpm/event/fdqueue.c server/mpm/event/fdqueue.h
Posted by Jim Jagielski <ji...@jaguNET.com>.
++1. Thanks for catching this; it explains some weirdness
I've been seeing lately!
On Aug 24, 2013, at 2:19 PM, Eric Covener <co...@gmail.com> wrote:
> On Sun, Jun 19, 2011 at 8:23 AM, <sf...@apache.org> wrote:
>> Author: sf
>> Date: Sun Jun 19 12:23:42 2011
>> New Revision: 1137358
>>
>> URL: http://svn.apache.org/viewvc?rev=1137358&view=rev
>> Log:
>> Some improvements for handling of many connections for MPM event:
>>
>> - Process lingering close asynchronously instead of tying up worker threads
>> (based on patch by Jeff Trawick).
>>
>
>> + /* socket is already in non-blocking state */
>> + do {
>> + nbytes = sizeof(dummybuf);
>> + rv = apr_socket_recv(csd, dummybuf, &nbytes);
>> + } while (rv == APR_SUCCESS);
>> +
>> + if (!APR_STATUS_IS_EOF(rv)) {
>> + return;
>> + }
>> +
>> + rv = apr_pollset_remove(event_pollset, pfd);
>> + AP_DEBUG_ASSERT(rv == APR_SUCCESS);
>
> I was looking at an issue in this area, it seems like the
> corresponding code in ap_lingering_close is not so picky about
> apr_socket_recv return code. It seems like we could continually get
> ECONNABORTED/ECONNRESET back and not take the socket out of the ring
> until the timeout elapses.
>
> I'm wondering if the test should be APR_STATUS_IS_EAGAIN(), and
> anything else that isn't success means we no longer need to linger?
>
Re: svn commit: r1137358 - in /httpd/httpd/trunk: CHANGES
include/ap_mmn.h include/http_connection.h include/httpd.h
include/scoreboard.h server/connection.c server/mpm/event/event.c
server/mpm/event/fdqueue.c server/mpm/event/fdqueue.h
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Aug 24, 2013 at 2:19 PM, Eric Covener <co...@gmail.com> wrote:
> On Sun, Jun 19, 2011 at 8:23 AM, <sf...@apache.org> wrote:
> > Author: sf
> > Date: Sun Jun 19 12:23:42 2011
> > New Revision: 1137358
> >
> > URL: http://svn.apache.org/viewvc?rev=1137358&view=rev
> > Log:
> > Some improvements for handling of many connections for MPM event:
> >
> > - Process lingering close asynchronously instead of tying up worker
> threads
> > (based on patch by Jeff Trawick).
> >
>
> > + /* socket is already in non-blocking state */
> > + do {
> > + nbytes = sizeof(dummybuf);
> > + rv = apr_socket_recv(csd, dummybuf, &nbytes);
> > + } while (rv == APR_SUCCESS);
> > +
> > + if (!APR_STATUS_IS_EOF(rv)) {
> > + return;
> > + }
> > +
> > + rv = apr_pollset_remove(event_pollset, pfd);
> > + AP_DEBUG_ASSERT(rv == APR_SUCCESS);
>
> I was looking at an issue in this area, it seems like the
> corresponding code in ap_lingering_close is not so picky about
> apr_socket_recv return code. It seems like we could continually get
> ECONNABORTED/ECONNRESET back and not take the socket out of the ring
> until the timeout elapses.
>
> I'm wondering if the test should be APR_STATUS_IS_EAGAIN(), and
> anything else that isn't success means we no longer need to linger?
>
Sounds right to me...
try to receive, get
a) APR_SUCCESS -- repeat
b) APR_EAGAIN -- wait for another event on the socket to be signaled
c) anything else, including APR timeout -- non-recoverable, ignored
--
Born in Roswell... married an alien...
http://emptyhammock.com/