httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: Window MPM debugging
Date Sat, 09 Feb 2002 17:02:32 GMT
Bill actually explained this on list already.

The problem is that we create 2 events in the Windows MPM, one for
restart, and one for shutdown.  In the version you grabbed, we are
creating the restart event and the shutdown event is not being created.
Which is why shutting down doesn't work.

Once Bill found that bug, he re-arranged the code to create the shutdown
event first.  His reasoning was simple, it is MUCH better to allow
people to stop the service and not allow them to restart, than it is to
do the opposite.

The real bug is that we are only creating one event the question is
which event is better to be creating.  Personally, I agree with Will,
letting people shutdown is actually much more important than allowing
them to restart.

However, if you want to get back to the same state, just switch the
order that we create the events.

Ryan

----------------------------------------------
Ryan Bloom                  rbb@covalent.net
645 Howard St.              rbb@apache.org
San Francisco, CA 

> -----Original Message-----
> From: Bill Stoddard [mailto:bill@wstoddard.com]
> Sent: Saturday, February 09, 2002 7:12 AM
> To: dev@httpd.apache.org
> Subject: Window MPM debugging
> 
> FYI... I downloaded the Windows MPM from 2.0.31 (including Ryan's
patch to
> get the MPM
> looking more like the Unix MPMs), changed ap_new_connection() to
> ap_run_create_connection() compiled it, and it works much better than
HEAD
> as a service
> (though I do not recommend shipping it :-)
> 
> apache -k restart -n apache2 works
> apache -k stop -n apache2 works
> apache -k shutdown -n apache2 is broken (and I understand why)
> 
> So, some commit between then and now broke restarts. Perhaps some code
> rearranging changed
> timings and exposed a bug that was always there but no one noticed.
Dunno,
> but it would
> make sense to start incrementally applying patches to the 2.0.31 level
and
> try to identify
> exactly when the breakage occured.
> 
> Bill



Mime
View raw message