Perrin Harkins wrote:
Then there is the bug of causing an infinite loop when Apache is
stopped probably because of undefined subroutine calls.
There's something wrong with your mod_perl build or some module you are
using. That isn't normal behavior, and it doesn't happen for me.
I'm using debian's apache-perl. I think I't got to do with OI2 code and
the behaviour reported wih undefined subroutine calls. It's documented
here among other places:
http://www.axint.net/apache/perl/mod_perl-1.29/faq/mod_perl_faq.pod
(find "Joel Wagner reports")
Apache tries to do a graceful shutdown, meaning it tries to handle any
connections that are currently operating. If you don't want it to do
that, you can kill it more harshly with a -9/-KILL. Not a problem on a
dev box where you are the only client.
This is true. After mulling about this thing yesterday I came to the
same conclusion that this would have helped.
Why do you have to stare at it?
Because I need to know when apache has correctly started and initialized
OI2 since before that I can't do my request. I need to stare it to know
when I can continue. With FastCGI I can do the restart at any time after
testing and it takes virtually no time to complete and never fails, so I
don't need to continue my actions the same instant it is ready. You are
correct that wil -9 kill I could bind apache stop & start also, but I
would somehow have to be ready to act when it's ready, since the only
time I can do the start part is after I have done all the editing and
I'm ready to test.
So the bonus for me here is just the fact that with FastCGI I can press
CTRL-R on my browser, which causes OI2 to initialize and does the
request without any user intervention between them. I still have to
stare at the browser window while OI2 is initializing ;)
This is the same thing why you do 'stop && start' and not issue 'stop',
wait for it to complete, and then issue 'start' yourself ;)
Since the code to be compiled and the setup to be created is identical
with any of these server options, the total time for restarting should
be the same.
If there weren't for the bugs mentioned, this would probably be very
close to the reality.
That's true, your images would end up waiting if you used apache in -X
mode. I don't think avoiding forking will make things start noticeably
faster anyway.
Things starting faster was not the point. The point was the amount of
time a forked child takes to execute it's first request, when compared
to a single process serving the result. But this might not be a really
noticeable issue anyway.
- Antti
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
|
