Re: [Openinteract-dev] Using FastCGI as development plaftorm

[<an...@io...>]

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