httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: svn commit: r1739876 - /httpd/httpd/branches/2.4.x/STATUS
Date Wed, 27 Apr 2016 14:15:51 GMT
For example... in event.c;

    if (cs->pub.state == CONN_STATE_WRITE_COMPLETION) {
        int not_complete_yet;

        ap_update_child_status_from_conn(sbh, SERVER_BUSY_WRITE, c);

Yuck, that just trashed the score for that connection.

We do it again here;

    if (cs->pub.state == CONN_STATE_LINGER) {
        start_lingering_close_blocking(cs);
    }
    else if (cs->pub.state == CONN_STATE_CHECK_REQUEST_LINE_READABLE) {
        ap_update_child_status_from_conn(sbh, SERVER_BUSY_KEEPALIVE, c);

I'm sure we can find similar examples, I'm still going through a pretty
broad grep of the trunk sources.





On Wed, Apr 27, 2016 at 8:43 AM, William A Rowe Jr <wrowe@rowe-clan.net>
wrote:

> I'm not certain the error is -in- scoreboard.c.
>
> Suspecting that we used to call ap_update_child_status[_xxx] with the
> NULL req/conn rec pointer when we were idling for keepalive or ending the
> request.
> It seems we may now be calling it in these situations with a now-NULL
> req_rec
> and the dying/idling conn_rec pointer, causing the request value to null
> out (or
> calling it with a descr pointer to "\0").
>
>
> On Wed, Apr 27, 2016 at 7:54 AM, Jim Jagielski <jim@jagunet.com> wrote:
>
>> +1...
>>
>> I had just applied the patch in STATUS w/o seeing this thread.
>> Best to just revert this all and get back to 2.4.18 behavior
>> (and code)
>>
>> > On Apr 27, 2016, at 12:40 AM, Stefan Eissing <
>> stefan.eissing@greenbytes.de> wrote:
>> >
>> >
>> >
>> >> Am 27.04.2016 um 03:53 schrieb William A Rowe Jr <wrowe@rowe-clan.net
>> >:
>> >>
>> >>
>> >> My gut instinct is to propose scoreboard.c for a full svn revert back
>> >> to a working state,
>> >
>> > I did not realize that it is that deep of a mess now. Please revert,
>> uncomment the new calls use in http2 and I'll find another approach there.
>> >
>> > It seems that there are a lot of expectations on how this part of the
>> server behaves, but no way to verify any changes/additions against them for
>> a newbie like me.
>> >
>> > Since this whole h2 thing is experimental and needs to evolve based on
>> user feedback, it better either use the extension possibilities of
>> mod_status or come up with a new, separate approach that allows frequent
>> changes.
>> >
>> > -Stefan
>>
>>
>

Mime
View raw message