You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Ames <gr...@remulak.net> on 2001/08/01 17:31:39 UTC
Re: ap_graceful_stop_signalled()
Jeff Trawick wrote:
>
> All this seems to be used for is to see if we should accept another
> request on a keepalive connection, so it seems fair to see if it can
> be changed.
>
> There are reasons other than graceful restart why we wouldn't want to
> accept another request:
>
> . MaxRequestsPerChild reached (a threaded MPM can reach that limit
> independent of what is happening on this connection)
>
> . some other sort of shutdown (yeah, graceless shouldn't care but we
> don't know how to knock out threads portably AFAIK; weird MPMs may
> have their own ideas about what to do)
>
> Why not replace ap_graceful_stop_signalled() with a call to
> ap_mpm_query(), as in:
>
> int mpm_exiting;
>
> ap_mpm_query(AP_MPMQ_IS_EXITING, &mpm_exiting);
> if (mpm_exiting) {
> break;
> }
>
> or something more explicit like
>
> AP_MPMQ_SHOULD_START_NEW_REQUEST <- yeah, stupid name
As I mentioned in the office yesterday, I think this is a good
(necessary?) idea. Consider what happens with an HTTP/1.1 proxy server
front end, pipelining & multiplexing requests over a single connection
to a back end server. That connection could keep pumping requests
forever, or at least until one of the servers dies.
This also would stop the phenomenon that Cliff discovered when he used
server-status?refresh=2 , which also pumps requests forever over a
connection. OTOH, it's a great way to hunt for bugs in p_i_s_m 8^)
Greg
Re: ap_graceful_stop_signalled()
Posted by Greg Ames <gr...@remulak.net>.
Ryan Bloom wrote:
>
> On Thursday 02 August 2001 10:24, Jeff Trawick wrote:
> >
> > The core needs to ask the MPM whether or not another request should be
> > accepted on the connection. This is a little more general than the
> > purpose of ap_graceful_stop_signalled().
>
> I disagree with that. The core is asking if the child is exiting gracefully. That is
> all it is asking.
No. First of all, it isn't the core, it's http. Jeff, shame! shame!
shame!
Ryan, now you're referring to an obsolete name, not what needs to happen
here. shame! shame! shame! ap_graceful_restart_signalled was an
appropriate name in 1.3 for a server which only did http, and used
signals all over the place to blow workers out of the water.
Let's say the 1.3 folks had named the function
ap_should_http_keepalive_read_loop_exit() That's the real question they
needed answered, and graceful restarts were the only case that wasn't
taken care of by signals. The name they chose was easier to type, and
appropriate at the time.
> The MPM does not and should not control if any more requests
> are to be served. That is up to the protocol itself.
and, appropriately enough, http is the caller of the function in
question.
> Now, as far as the child process
> is concerned, every reason to shutdown gracefully can and should be handled the
> same way.
I agree that they should, but they aren't. SIGWINCH/apachectl graceful
is allowed to exit the HTTP keepalive read loop, the rest can loop
forever.
> I can easily imagine some protocols that want to continue serving requests, even if
> the server is restarting, think FTP or POP3. But some, want to cut off the client after
> a given number of requests, such as HTTP.
OK, no problem. If that's the case, FTP and POP3 shouldn't call the
function that asks the MPM if it is trying to shut down the process.
I'll commit a change to worker and threaded to solve the HTTP infinite
loop problem, now that we understand that this won't hurt other
protocols. It sounds like it will take longer to choose a better name
for the function.
Greg
Re: ap_graceful_stop_signalled()
Posted by Ryan Bloom <rb...@covalent.net>.
On Thursday 02 August 2001 10:24, Jeff Trawick wrote:
> Ryan Bloom <rb...@covalent.net> writes:
> > Wait a second, I'm confused. Jeff, if I read your message correctly, you
> > are saying that you want to remove the ap_graceful_stop_signalled()
> > function with an ap_mpm_query call. You don't want to add any new
> > functionality, just change how we determine what is going on.
>
> ...
>
> > As for changing the function, -0.5. I don't care if we change the name
> > of the function, but this kind of thing doesn't belong in the
> > ap_mpm_query function. That function should be used to query information
> > about the MPM, and the current configuration. It should not be used to
> > track the state of the MPM.
>
> The core needs to ask the MPM whether or not another request should be
> accepted on the connection. This is a little more general than the
> purpose of ap_graceful_stop_signalled().
I disagree with that. The core is asking if the child is exiting gracefully. That is
all it is asking. The MPM does not and should not control if any more requests
are to be served. That is up to the protocol itself. Now, as far as the child process
is concerned, every reason to shutdown gracefully can and should be handled the
same way.
I can easily imagine some protocols that want to continue serving requests, even if
the server is restarting, think FTP or POP3. But some, want to cut off the client after
a given number of requests, such as HTTP.
> We can rename ap_graceful_stop_signalled() to something more
> appropriate and also tweak the internals to reflect other reasons why
> core shouldn't accept another request.
>
> Anybody got a favorite name?
>
> ap_mpm_server_exiting() return non-zero if this process going away
> ap_mpm_accepting_requests() return zero if this process going away
I disagree with this. See above.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: ap_graceful_stop_signalled()
Posted by Greg Ames <gr...@remulak.net>.
Jeff Trawick wrote:
>
> Ryan Bloom <rb...@covalent.net> writes:
>
> > Wait a second, I'm confused. Jeff, if I read your message correctly, you are
> > saying that you want to remove the ap_graceful_stop_signalled() function with
> > an ap_mpm_query call. You don't want to add any new functionality, just change
> > how we determine what is going on.
> ...
> > As for changing the function, -0.5. I don't care if we change the name of the
> > function, but this kind of thing doesn't belong in the ap_mpm_query function.
> > That function should be used to query information about the MPM, and the
> > current configuration. It should not be used to track the state of the MPM.
>
> The core needs to ask the MPM whether or not another request should be
> accepted on the connection. This is a little more general than the
> purpose of ap_graceful_stop_signalled().
>
> We can rename ap_graceful_stop_signalled() to something more
> appropriate and also tweak the internals to reflect other reasons why
> core shouldn't accept another request.
>
I'll tweak threaded and worker to return "workers_may_exit" ASAP, and
wait for feedback on the naming.
> Anybody got a favorite name?
>
> ap_mpm_server_exiting() return non-zero if this process going away
I like this name best, but "server" bothers me some (someone might think
it refers to all of Apache). How about: ap_mpm_process_exiting()
(same return spec as above)
> ap_mpm_accepting_requests() return zero if this process going away
not bad either, but I think one of the "exiting" names gets the point
across more directly.
Greg
p.s. my apologies if I caused any confusion. I didn't realize there was
an existing callback directly into all the MPMs right where we need it.
Re: ap_graceful_stop_signalled()
Posted by Jeff Trawick <tr...@attglobal.net>.
Ryan Bloom <rb...@covalent.net> writes:
> Wait a second, I'm confused. Jeff, if I read your message correctly, you are
> saying that you want to remove the ap_graceful_stop_signalled() function with
> an ap_mpm_query call. You don't want to add any new functionality, just change
> how we determine what is going on.
...
> As for changing the function, -0.5. I don't care if we change the name of the
> function, but this kind of thing doesn't belong in the ap_mpm_query function.
> That function should be used to query information about the MPM, and the
> current configuration. It should not be used to track the state of the MPM.
The core needs to ask the MPM whether or not another request should be
accepted on the connection. This is a little more general than the
purpose of ap_graceful_stop_signalled().
We can rename ap_graceful_stop_signalled() to something more
appropriate and also tweak the internals to reflect other reasons why
core shouldn't accept another request.
Anybody got a favorite name?
ap_mpm_server_exiting() return non-zero if this process going away
ap_mpm_accepting_requests() return zero if this process going away
?????
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: ap_graceful_stop_signalled()
Posted by Ryan Bloom <rb...@covalent.net>.
Wait a second, I'm confused. Jeff, if I read your message correctly, you are
saying that you want to remove the ap_graceful_stop_signalled() function with
an ap_mpm_query call. You don't want to add any new functionality, just change
how we determine what is going on.
Greg, you seem to be saying that we do need this ability. We already have the
ability, don't we?
As for changing the function, -0.5. I don't care if we change the name of the
function, but this kind of thing doesn't belong in the ap_mpm_query function.
That function should be used to query information about the MPM, and the
current configuration. It should not be used to track the state of the MPM.
Ryan
On Wednesday 01 August 2001 08:31, Greg Ames wrote:
> Jeff Trawick wrote:
> > All this seems to be used for is to see if we should accept another
> > request on a keepalive connection, so it seems fair to see if it can
> > be changed.
> >
> > There are reasons other than graceful restart why we wouldn't want to
> > accept another request:
> >
> > . MaxRequestsPerChild reached (a threaded MPM can reach that limit
> > independent of what is happening on this connection)
> >
> > . some other sort of shutdown (yeah, graceless shouldn't care but we
> > don't know how to knock out threads portably AFAIK; weird MPMs may
> > have their own ideas about what to do)
> >
> > Why not replace ap_graceful_stop_signalled() with a call to
> > ap_mpm_query(), as in:
> >
> > int mpm_exiting;
> >
> > ap_mpm_query(AP_MPMQ_IS_EXITING, &mpm_exiting);
> > if (mpm_exiting) {
> > break;
> > }
> >
> > or something more explicit like
> >
> > AP_MPMQ_SHOULD_START_NEW_REQUEST <- yeah, stupid name
>
> As I mentioned in the office yesterday, I think this is a good
> (necessary?) idea. Consider what happens with an HTTP/1.1 proxy server
> front end, pipelining & multiplexing requests over a single connection
> to a back end server. That connection could keep pumping requests
> forever, or at least until one of the servers dies.
>
> This also would stop the phenomenon that Cliff discovered when he used
> server-status?refresh=2 , which also pumps requests forever over a
> connection. OTOH, it's a great way to hunt for bugs in p_i_s_m 8^)
>
> Greg
--
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------