You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Shibi Ns <sh...@gmail.com> on 2012/03/02 09:20:30 UTC
Terminating Child process Dynamically
I would like terminate current sever Child process after the end of
current request because some data is cached and data is changed after the
process creation. The data cached during InitChild phase
Is it possible ?
Which phase should i do this
--
--Shibi Ns--
Re: Terminating Child process Dynamically
Posted by Perrin Harkins <pe...@elem.com>.
- Perrin
On Mar 7, 2012 7:00 AM, "Torsten Förtsch" <to...@gmx.net> wrote:
> On Friday, 02 March 2012 13:49:34 Perrin Harkins wrote:
> > You can use $r-->child_terminate().
>
> 2 remarks:
>
> 1) you can use this method at any point in the request cycle. It marks the
> process to be terminated when the current request is done.
>
> 2) the way child_terminate() exits is quite nasty because it simply calls
> exit() at C level. That means neither END blocks nor PerlChildExitHandlers
> are
> executed nor are static perl objects destroyed.
>
> Perhaps a more perlish way to terminate the current process is
>
> {
> package My::Terminator;
> sub DESTROY {CORE::exit 0}
> sub new {return bless \my $dummy, __PACKAGE__}
> }
> $r->pnotes->{terminator}=My::Terminator->new;
>
> Thus, global Perl objects will be destroyed properly and the process exits
> when the current request is done.
>
> If you are already using some kind of scope guard module (e.g. Guard) you
> can
> achieve the same even simpler:
>
> $r->pnotes->{terminator}=guard {CORE::exit 0};
>
> Torsten Förtsch
>
> --
> Need professional modperl support? Hire me! (http://foertsch.name)
>
> Like fantasy? http://kabatinte.net
>
Re: Terminating Child process Dynamically
Posted by Perrin Harkins <pe...@elem.com>.
2012/3/7 Torsten Förtsch <to...@gmx.net>:
> Yes, in mp1 it did. Not so in mp2.
Oh, I see this was covered on the dev list. It doesn't call
perl_destruct() because it may be running under threads, which mp1
didn't need to worry about.
- Perrin
Re: Terminating Child process Dynamically
Posted by Torsten Förtsch <to...@gmx.net>.
On Wednesday, 07 March 2012 08:06:37 Perrin Harkins wrote:
> It doesn't call perl_destruct()? I thought it did in mod_perl 1
Yes, in mp1 it did. Not so in mp2.
static apr_status_t child_terminate(void *data) {
apr_pool_t *pool = (apr_pool_t *)data;
/* On the first pass, re-register so we end up last */
if (data) {
apr_pool_cleanup_register(pool, NULL, child_terminate,
apr_pool_cleanup_null);
}
else {
exit(0);
}
return APR_SUCCESS;
}
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Re: Terminating Child process Dynamically
Posted by Perrin Harkins <pe...@elem.com>.
[Sorry, that last message was sent by accident. I set my phone to
require confirmation so it won't happen again.]
2012/3/7 Torsten Förtsch <to...@gmx.net>:
> 2) the way child_terminate() exits is quite nasty because it simply calls
> exit() at C level. That means neither END blocks nor PerlChildExitHandlers are
> executed nor are static perl objects destroyed.
It doesn't call perl_destruct()? I thought it did in mod_perl 1:
http://perl.apache.org/docs/general/control/control.html#Speeding_up_the_Apache_Termination_and_Restart
- Perrin
Re: Terminating Child process Dynamically
Posted by Torsten Förtsch <to...@gmx.net>.
On Friday, 02 March 2012 13:49:34 Perrin Harkins wrote:
> You can use $r-->child_terminate().
2 remarks:
1) you can use this method at any point in the request cycle. It marks the
process to be terminated when the current request is done.
2) the way child_terminate() exits is quite nasty because it simply calls
exit() at C level. That means neither END blocks nor PerlChildExitHandlers are
executed nor are static perl objects destroyed.
Perhaps a more perlish way to terminate the current process is
{
package My::Terminator;
sub DESTROY {CORE::exit 0}
sub new {return bless \my $dummy, __PACKAGE__}
}
$r->pnotes->{terminator}=My::Terminator->new;
Thus, global Perl objects will be destroyed properly and the process exits
when the current request is done.
If you are already using some kind of scope guard module (e.g. Guard) you can
achieve the same even simpler:
$r->pnotes->{terminator}=guard {CORE::exit 0};
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Re: Terminating Child process Dynamically
Posted by Perrin Harkins <pe...@elem.com>.
On Fri, Mar 2, 2012 at 3:20 AM, Shibi Ns <sh...@gmail.com> wrote:
> I would like terminate current sever Child process after the end of current
> request because some data is cached and data is changed after the process
> creation. The data cached during InitChild phase
>
> Is it possible ?
It certainly is! You can use $r-->child_terminate(). You might put
this in a cleanup handler. You can see example code in
Apache2::SizeLimit.
However, this isn't what I would do. I would make a cleanup handler
that checks somehow to see if the data has changed (stat a file for
modtime?) and then reloads the data. It's more efficient than
spawning a new process, albeit somewhat more complicated.
- Perrin
Re: Terminating Child process Dynamically
Posted by Vincent Veyron <vv...@wanadoo.fr>.
Le vendredi 02 mars 2012 à 15:53 +0530, Shibi Ns a écrit :
> Not each request , it's based some data change in database and this
I can't help directly, but your post reminded me of this quote :
There are only two hard things in Computer Science: cache
invalidation and naming things.
-- Phil Karlton
--
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres et des contentieux pour le service juridique
Re: Terminating Child process Dynamically (and keeping huge amounts of data in RAM)
Posted by Randolf Richardson <ra...@modperl.pl>.
> Bouncing means restart the application to bring the current changes and new
> data to the cache. We can't use the following logic as there are huge
> number of existing data cache and perl modules involved. So the changes
> will be massive.
Keeping code in RAM is fine (that's one of the points of mod_perl
and mod_perl2 -- to keep the compiled version available for immediate
use, hence this can, and often does as I've observed, yield shorter
response times than serving non-dynamic HTML files from disk).
Keeping small amounts of data in RAM is also fine, but keeping huge
amounts seems unusual. I'm currently working on a web site that has
data stored in PostgreSQL, for which my mod_perl2 code will
effectively generate more than 2.6 million web pages (user-driven
activity will gradually cause this to increase); although I suppose I
could load all this data in RAM on a server with 32 GBs of RAM (the
database consumes nearly 20 GBs of disk space), to me it seems far
more practical to use the database on disk, partly because I expect
that most of the data will not actually be needed most of the time.
I do find it interesting that you're storing huge amounts of data in
RAM, and I wonder what some of your reasons are for doing this.
[End of reply.]
> Shibi
>
>
> On Fri, Mar 2, 2012 at 4:51 PM, André Warnier <aw...@ice-sa.com> wrote:
>
> > On Fri, Mar 2, 2012 at 3:32 PM, André Warnier <aw...@ice-sa.com> wrote:
> >>
> >> Shibi Ns wrote:
> >>>
> >>> I would like terminate current sever Child process after the end of
> >>>> current request because some data is cached and data is changed after
> >>>> the
> >>>> process creation. The data cached during InitChild phase
> >>>>
> >>>> Is it possible ?
> >>>>
> >>>> It is certainly possible (*), but really, really, really inefficient.
> >>>>
> >>> You are going to force your Apache server to create a new child process
> >>> for each HTTP request ? That sounds crazy.
> >>> You should review your application logic instead.
> >>>
> >>>
> >>> (*) The easiest way would be to set MaxRequestsPerChild to 1 in your
> >>> server configuration.
> >>> But don't think that I would recommend doing that.
> >>>
> >>>
> >> Shibi Ns wrote:
> > > Not each request , it's based some data change in database and this could
> > > happen couple of times in day that's all. We really don't want to go
> > ahead
> > > bounce the application in order refresh the cache
> > >
> >
> > I don't now what you mean by "bounce the application", but why do you not
> > do something like this :
> >
> > At the beginning of your first "handler" :
> >
> > our $CACHED_DATA;
> >
> > unless (defined $CACHED_DATA) {
> > $CACHED_DATA = _load_cached_data();
> > }
> >
> > ....
> >
> > within the request processing :
> >
> > our $CACHED_DATA;
> >
> > if ($condition) {
> > $CACHED_DATA = undef;
> > }
> > return OK;
> >
> > ...
> >
> > sub _load_cached_data {
> > # load and cache whatever data needs be
> > my $cached_data;
> >
> > ...
> >
> > return $cached_data;
> > }
> >
> >
> >
>
>
> --
> --Shibi Ns--
>
Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/
Re: Terminating Child process Dynamically
Posted by Dave Hodgkinson <da...@gmail.com>.
On 2 Mar 2012, at 19:04, Shibi Ns wrote:
>
> Bouncing means restart the application to bring the current changes and new data to the cache. We can't use the following logic as there are huge number of existing data cache and perl modules involved. So the changes will be massive.
>
> Shibi
>
this makes me think your architecture is wrong.
Re: Terminating Child process Dynamically
Posted by Shibi Ns <sh...@gmail.com>.
Bouncing means restart the application to bring the current changes and new
data to the cache. We can't use the following logic as there are huge
number of existing data cache and perl modules involved. So the changes
will be massive.
Shibi
On Fri, Mar 2, 2012 at 4:51 PM, André Warnier <aw...@ice-sa.com> wrote:
> On Fri, Mar 2, 2012 at 3:32 PM, André Warnier <aw...@ice-sa.com> wrote:
>>
>> Shibi Ns wrote:
>>>
>>> I would like terminate current sever Child process after the end of
>>>> current request because some data is cached and data is changed after
>>>> the
>>>> process creation. The data cached during InitChild phase
>>>>
>>>> Is it possible ?
>>>>
>>>> It is certainly possible (*), but really, really, really inefficient.
>>>>
>>> You are going to force your Apache server to create a new child process
>>> for each HTTP request ? That sounds crazy.
>>> You should review your application logic instead.
>>>
>>>
>>> (*) The easiest way would be to set MaxRequestsPerChild to 1 in your
>>> server configuration.
>>> But don't think that I would recommend doing that.
>>>
>>>
>> Shibi Ns wrote:
> > Not each request , it's based some data change in database and this could
> > happen couple of times in day that's all. We really don't want to go
> ahead
> > bounce the application in order refresh the cache
> >
>
> I don't now what you mean by "bounce the application", but why do you not
> do something like this :
>
> At the beginning of your first "handler" :
>
> our $CACHED_DATA;
>
> unless (defined $CACHED_DATA) {
> $CACHED_DATA = _load_cached_data();
> }
>
> ....
>
> within the request processing :
>
> our $CACHED_DATA;
>
> if ($condition) {
> $CACHED_DATA = undef;
> }
> return OK;
>
> ...
>
> sub _load_cached_data {
> # load and cache whatever data needs be
> my $cached_data;
>
> ...
>
> return $cached_data;
> }
>
>
>
--
--Shibi Ns--
Re: Terminating Child process Dynamically
Posted by André Warnier <aw...@ice-sa.com>.
> On Fri, Mar 2, 2012 at 3:32 PM, André Warnier <aw...@ice-sa.com> wrote:
>
>> Shibi Ns wrote:
>>
>>> I would like terminate current sever Child process after the end of
>>> current request because some data is cached and data is changed after the
>>> process creation. The data cached during InitChild phase
>>>
>>> Is it possible ?
>>>
>>> It is certainly possible (*), but really, really, really inefficient.
>> You are going to force your Apache server to create a new child process
>> for each HTTP request ? That sounds crazy.
>> You should review your application logic instead.
>>
>>
>> (*) The easiest way would be to set MaxRequestsPerChild to 1 in your
>> server configuration.
>> But don't think that I would recommend doing that.
>>
>
Shibi Ns wrote:
> Not each request , it's based some data change in database and this could
> happen couple of times in day that's all. We really don't want to go ahead
> bounce the application in order refresh the cache
>
I don't now what you mean by "bounce the application", but why do you not do something
like this :
At the beginning of your first "handler" :
our $CACHED_DATA;
unless (defined $CACHED_DATA) {
$CACHED_DATA = _load_cached_data();
}
....
within the request processing :
our $CACHED_DATA;
if ($condition) {
$CACHED_DATA = undef;
}
return OK;
...
sub _load_cached_data {
# load and cache whatever data needs be
my $cached_data;
...
return $cached_data;
}
Re: Terminating Child process Dynamically
Posted by Shibi Ns <sh...@gmail.com>.
Not each request , it's based some data change in database and this could
happen couple of times in day that's all. We really don't want to go ahead
bounce the application in order refresh the cache
On Fri, Mar 2, 2012 at 3:32 PM, André Warnier <aw...@ice-sa.com> wrote:
> Shibi Ns wrote:
>
>> I would like terminate current sever Child process after the end of
>> current request because some data is cached and data is changed after the
>> process creation. The data cached during InitChild phase
>>
>> Is it possible ?
>>
>> It is certainly possible (*), but really, really, really inefficient.
> You are going to force your Apache server to create a new child process
> for each HTTP request ? That sounds crazy.
> You should review your application logic instead.
>
>
> (*) The easiest way would be to set MaxRequestsPerChild to 1 in your
> server configuration.
> But don't think that I would recommend doing that.
>
--
--Shibi Ns--
Re: Terminating Child process Dynamically
Posted by André Warnier <aw...@ice-sa.com>.
Shibi Ns wrote:
> I would like terminate current sever Child process after the end of
> current request because some data is cached and data is changed after the
> process creation. The data cached during InitChild phase
>
> Is it possible ?
>
It is certainly possible (*), but really, really, really inefficient. You are going to
force your Apache server to create a new child process for each HTTP request ? That sounds
crazy.
You should review your application logic instead.
(*) The easiest way would be to set MaxRequestsPerChild to 1 in your server configuration.
But don't think that I would recommend doing that.