You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Warren D. Johnson" <wa...@jtechgrp.com> on 2000/09/04 00:04:51 UTC

StatINC Question

Regards all,

I've installed mod_perl and latest version of apache.  Everything seems to
be working fine.

I have set StatINC as the PerlInitHandler in my httpd.conf so as to stat()
file and libraries which are are dependencies of scripts handled by the
modperl handler.  In addition, I have a startup file which is run early on
in my .conf to add another lib to the @inc (or is it %INC?) variable so
StatINC will check in the necessary directories.

Here is my problem:  StatINC seems to work fine several times after I
restart the server but then at some point begins to act funky.  I'll reload
a page and either/or a source file will get reloaded every time (despite
it's time not changing)  or i'll get different versions of the page popping
up (versions which existed in previous revision of my source file).  Its
from looking at my error_log that different httpd child processes are
catching the different browser requests and reloading the source files.
It is extremely frustrating to say the least as I can't understand what the
problem really is.  Logic would dictate that if a httpd child process
received a request to handle a mod-perl-script that StatINC would tell the
server to hold up for a second while it recompiles these modules and then
let it go on it's way.  It's almost as if each child process maintains it's
own seperate cached version of the modperl-covered scripts.  Is this the
case?

Does anyone have any ideas?



Re: StatINC Question

Posted by Ask Bjoern Hansen <as...@apache.org>.
On Mon, 4 Sep 2000, Warren D. Johnson wrote:

> Thank you for the followup.  My original thought was that StatINC reloaded
> modules as appropriate and that each child should share a common cache of
> pre-compiled scripts.  Since that is not the case, it makes developing
> larger applications in mod_perl a bit trickier.  Trickier because now
> everytime I modify some  file that falls under the supervision of StatINC I
> have to do a graceful restart to get all the scripts
> re-synchronized/recompiled/reloaded.  Is there any other way around this?

Not really.

My trick is usually to partly getting used to just restart the whole
server (apachectl stop && sleep 2 && apachectl start) and partly to
write as much of the code in a way so it can be tested outside of
the mod_perl environment. That's a good thing to do anyway as it
will allow you to take things down to something much simpler for
testing and debugging. It will also allow you to use the code for
other things.

-- 
ask bjoern hansen - <http://www.netcetera.dk/~ask/>
more than 70M impressions per day, <http://valueclick.com>


Re: StatINC Question

Posted by "Warren D. Johnson" <wa...@jtechgrp.com>.
Matt,

Thank you for the followup.  My original thought was that StatINC reloaded
modules as appropriate and that each child should share a common cache of
pre-compiled scripts.  Since that is not the case, it makes developing
larger applications in mod_perl a bit trickier.  Trickier because now
everytime I modify some  file that falls under the supervision of StatINC I
have to do a graceful restart to get all the scripts
re-synchronized/recompiled/reloaded.  Is there any other way around this?
Can you force the apache's child processes to all use the same cache ?  I've
resorted to using PerlRun until it's time to go production, then i will
switch to full modperl.

Hm, thanks!

-Warren

[SNIP, SNIP, SNIP]

> > received a request to handle a mod-perl-script that StatINC would tell
the
> > server to hold up for a second while it recompiles these modules and
then
> > let it go on it's way.  It's almost as if each child process maintains
it's
> > own seperate cached version of the modperl-covered scripts.  Is this the
> > case?
>
> Yes, this is the case. Each child has its own copy of the compiled
> module. When you initially start the server, if your modules are
> pre-loaded, initially this memory will be copy-on-write shared across each
> child (i.e. only one area of memory used and shared between the children),
> but when you reload them using something like StatINC, that sharing
> disappears.
>
> You could try PerlFreshRestart and issue a graceful restart if this isn't
>


Re: StatINC Question

Posted by Matt Sergeant <ma...@sergeant.org>.
On Sun, 3 Sep 2000, Warren D. Johnson wrote:

> Here is my problem:  StatINC seems to work fine several times after I
> restart the server but then at some point begins to act funky.  I'll reload
> a page and either/or a source file will get reloaded every time (despite
> it's time not changing)  or i'll get different versions of the page popping
> up (versions which existed in previous revision of my source file).  Its
> from looking at my error_log that different httpd child processes are
> catching the different browser requests and reloading the source files.
> It is extremely frustrating to say the least as I can't understand what the
> problem really is.  Logic would dictate that if a httpd child process
> received a request to handle a mod-perl-script that StatINC would tell the
> server to hold up for a second while it recompiles these modules and then
> let it go on it's way.  It's almost as if each child process maintains it's
> own seperate cached version of the modperl-covered scripts.  Is this the
> case?

Yes, this is the case. Each child has its own copy of the compiled
module. When you initially start the server, if your modules are
pre-loaded, initially this memory will be copy-on-write shared across each
child (i.e. only one area of memory used and shared between the children),
but when you reload them using something like StatINC, that sharing
disappears.

You could try PerlFreshRestart and issue a graceful restart if this isn't
the type of reload you want.

-- 
<Matt/>

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org