Hi,

I have now created two patches: one for trunk and one for 2.2.x The
approach I used is as follows.

TRUNK
=====

1. Set the mpm_state to AP_MPMQ_STOPPING


2.2.x BRANCH
============

1. Set the mpm_state to AP_MPMQ_STOPPING
2. Return the correct value from ap_graceful_stop_signalled()

I considered rewriting http_core.c and http_protocol.c in 2.2.x to use
ap_mpm_query(). However third party modules may use
ap_graceful_stop_signalled(), so it needed to be fixed anyway, and I
didn't want to risk breaking code in http_core and http_protocol that
was working well. 

*All* other mpms support ap_graceful_stop_signalled() in 2.2.x, except
Netware.


OTHER MPMS
==========

I had a quick check through other 2.2.x MPMs and noticed that the
Netware MPM appears to have the same issue as prefork. I am not a
netware expert, so it might be good to have someone check that out.

Please send any feedback.

Thanks
-Andrew

On Wed, 2011-02-02 at 07:43 +0000, Ruediger Pluem wrote:
> 
> On 02/02/2011 12:57 AM, Andrew Punch wrote:
> > Hi,
> > 
> > I have contributed a patch to the long-standing bug 41743. A summary of
> > the issue is that if a keep-alive connection is active then the child
> > process never exits in certain cases (see bug for full details).
> > 
> > The expected behaviour, the behaviour of worker and the behaviour of 1.3
> > is that a "Connection: close" is issued then the connection is closed.
> > 
> > I have created a patch which simply returns die_now from the function
> > ap_graceful_stop_signalled()
> > 
> > Joe Orton commented:
> >> The fix for this on the trunk was r645434, which replaced use of
> >> ap_graceful_stop_signalled() with ap_mpm_query().
> > 
> >> This does look insufficient to fix the bug for prefork, since the
> > prefork
> >> signal handler does not change mpm_state (prefork.c:sig_term).
> > 
> > So my question is which of these alternatives do you prefer:
> > 1. Move ahead with my current patch
> > 2. I modify prefork.c so the signal handler changes mpm_state
> 
> Without looking into further details I guess we should follow the trunk
> fix (r645434) mentioned by Joe in the Bugzilla comment and try to backport it.
> Can you please try if this patch 
> (http://svn.apache.org/viewvc?view=revision&revision=645434)
> fixes your issue as well?
> 
> Regards
> 
> RĂ¼diger
> 


Reply via email to