Bill, submitted in trunk and proposed for 2.4.x. Thanks for testing. -Stefan
> Am 11.04.2017 um 15:30 schrieb William A Rowe Jr <[email protected]>: > > Great news, thanks Steffen! > > Stefan - if you apply to trunk and 2.4.x (I'm already +1 on inspection) I have > regression testing on Windows to do today and tomorrow and can give this > a little more exercise. > > Cheers, > > Bill > > > On Tue, Apr 11, 2017 at 5:27 AM, Steffen <[email protected]> wrote: >> Running now with Patch on AL windows with v1.10.1-git, nghttp2 1.21.1 , no >> warning anymore seen. >> >> >> >> On Tuesday 11/04/2017 at 10:23, Stefan Eissing wrote: >> >> >> Am 03.04.2017 um 21:17 schrieb William A Rowe Jr <[email protected]>: >> >> On Mon, Apr 3, 2017 at 8:21 AM, Eric Covener <[email protected]> wrote: >> >> On Mon, Apr 3, 2017 at 9:07 AM, Stefan Eissing >> <[email protected]> wrote: >> >> Question is: do we "fix" mpm_winnt or is there a better way for mod_http2 to >> shutdown the connection before mod_ssl does. This would need to work in >> async mpms for any connection state. >> >> >> I think it's okay to add the prep cal when short-circuiting lingering >> close, but it seems like very little extra will be running in the full >> call either. >> >> >> Jeff Trawick knew this bit of logic better than most any of us, I'd love >> to hear his thoughts on the cleanest solution. But fixing mpm_winnt >> to behave as the other MPM's would be worthwhile. It's also worth >> looking at third party MPM's such as mpm_itk to see if we have an >> underlying bug that must be fixed. >> >> I presume we still allow the disconnected socket to be recycled, which >> was the underlying idea behind the shortcut/optimization. It seems that >> the shortcut isn't (valid). >> >> >> All other of our mpms in trunk call ap_lingering_close() unconditionally >> after ap_process_connection(). So, mod_http2 should be fine there. >> >> mpm_itk, in the latest release at least, also always invokes >> ap_lingering_close() before terminating a connection. >> >> >> I propose the following patch for trunk and, if it does indeed work >> as expected will propose backport to 2.4.x. Since I do not run a >> Windows build, I'd like to hear peoples opinion and need a tester. >> >> Index: server/mpm/winnt/child.c >> =================================================================== >> --- server/mpm/winnt/child.c (revision 1790842) >> +++ server/mpm/winnt/child.c (working copy) >> @@ -817,10 +817,8 @@ >> >> if (!disconnected) { >> context->accept_socket = INVALID_SOCKET; >> - if (!c->aborted) { >> - ap_lingering_close(c); >> - } >> } >> + ap_lingering_close(c); >> } >> >> ap_update_child_status_from_indexes(0, thread_num, SERVER_DEAD, NULL); >> >> Steffen, if you want to try this in your Windows build, I attached the >> file from 2.4.x with the patch applied. >> >> >>
