RE: Trouble with AxKit at runtime - XML parsing stage

["Khachaturov, Vassilii" <Va...@comverse-in.com>]

I take your answer as a polite confirmation that I am the only one to make
that mistake :-)
Well, this seems to be the case. Now that I know the problem cause, this
*is* obvious. 

Still, the guide doesn't clear things IMHO for one under the same weird
false assumption that I had: "but the parent does not exit. Instead, the
parent re-reads its configuration files, spawns a new set of child processes
and continues to serve requests. It is almost equivalent to stopping and
then restarting the server. " It seems a subtle point indeed - that although
the libperl.so is external, it has already been mapped into the core back at
the runtime loader stage, and will never be reloaded. Until I asked myself
this question in this form (what exactly happens with the apache core and
why isn't the module reloaded?) I didn't get it.

I wonder why I was so sure that apache re-exec's itself. I am sure I saw it
in some public domain server after our homegrown webserver implementation
had done it that way, some 6 years ago. Was it cern httpd then, rather than
ncsa/apache? Well, I could also notice there is no "-listen-fd 4" or smth.
argument in the respawned httpd process cmdline, to tell the restarting
process where to take the listening socket... I like this technique because
it ensures there is no resource leak (other than, possibly, forgotten open
fds) on restart. Do you know if really many people suffer from the memory
leaks you mention at the link you gave? Should I patch apache so it has such
restart semantics in addition to (as another sighandler?
configurable?)/instead the current HUP behaviour? I mean, will such patch be
really useful for someone?

Vassilii

-----Original Message-----
From: Stas Bekman [mailto:stas@stason.org]
Sent: Friday, December 15, 2000 11:50 AM
To: Khachaturov, Vassilii
Cc: 'axkit-users@axkit.org'
Subject: RE: Trouble with AxKit at runtime - XML parsing stage 



> Stas: maybe you could add a small section to your Guide elaborating on
> dependencies of things and what has to be remade when things are upgraded?
> (Or I am the only one to make such stupid mistake?)

Well, it's documentated:
http://perl.apache.org/guide/control.html#Restarting_Techniques 

Of course you cannot send a process the HUP signal and expect it to fully
stop and re-start, unless you know that it does that.

Isn't it obvious that when you upgrade some binary you should quit the
program that's depending on it and restart it?

RE: Trouble with AxKit at runtime - XML parsing stage

[Stas Bekman <st...@stason.org>]

> I take your answer as a polite confirmation that I am the only one to make
> that mistake :-)
> Well, this seems to be the case. Now that I know the problem cause, this
> *is* obvious. 
> 
> Still, the guide doesn't clear things IMHO for one under the same weird
> false assumption that I had: "but the parent does not exit. Instead, the
> parent re-reads its configuration files, spawns a new set of child processes
> and continues to serve requests. It is almost equivalent to stopping and
> then restarting the server. " It seems a subtle point indeed - that although
> the libperl.so is external, it has already been mapped into the core back at
> the runtime loader stage, and will never be reloaded. Until I asked myself
> this question in this form (what exactly happens with the apache core and
> why isn't the module reloaded?) I didn't get it.

If you think it's misleading you are always welcome to send me the patch
which is clearer, that's how the guide has evolved and corrected itself so
far.

> I wonder why I was so sure that apache re-exec's itself. I am sure I saw it
> in some public domain server after our homegrown webserver implementation
> had done it that way, some 6 years ago. Was it cern httpd then, rather than
> ncsa/apache? Well, I could also notice there is no "-listen-fd 4" or smth.
> argument in the respawned httpd process cmdline, to tell the restarting
> process where to take the listening socket... I like this technique because
> it ensures there is no resource leak (other than, possibly, forgotten open
> fds) on restart. Do you know if really many people suffer from the memory
> leaks you mention at the link you gave? Should I patch apache so it has such
> restart semantics in addition to (as another sighandler?
> configurable?)/instead the current HUP behaviour? I mean, will such patch be
> really useful for someone?

Most of the people don't use HUP to restart, in fact I've never used HUP
with mod_perl. YMMV. I do it this way:

stop; sleep 2; restart;
where stop and restart are aliases for apachectl stop|restart

> 
> Vassilii
> 
> -----Original Message-----
> From: Stas Bekman [mailto:stas@stason.org]
> Sent: Friday, December 15, 2000 11:50 AM
> To: Khachaturov, Vassilii
> Cc: 'axkit-users@axkit.org'
> Subject: RE: Trouble with AxKit at runtime - XML parsing stage 
> 
> 
> 
> > Stas: maybe you could add a small section to your Guide elaborating on
> > dependencies of things and what has to be remade when things are upgraded?
> > (Or I am the only one to make such stupid mistake?)
> 
> Well, it's documentated:
> http://perl.apache.org/guide/control.html#Restarting_Techniques 
> 
> Of course you cannot send a process the HUP signal and expect it to fully
> stop and re-start, unless you know that it does that.
> 
> Isn't it obvious that when you upgrade some binary you should quit the
> program that's depending on it and restart it?
> 
> 



_____________________________________________________________________
Stas Bekman              JAm_pH     --   Just Another mod_perl Hacker
http://stason.org/       mod_perl Guide  http://perl.apache.org/guide 
mailto:stas@stason.org   http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/