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 <wr...@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 <j...@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.eiss...@greenbytes.de> wrote:
>> >
>> >
>> >
>> >> Am 27.04.2016 um 03:53 schrieb William A Rowe Jr <wr...@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
>>
>>
>
