Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: ModPerl

Terminating Child process Dynamically

 

 

ModPerl modperl RSS feed   Index | Next | Previous | View Threaded


shibi.ns at gmail

Mar 2, 2012, 12:20 AM

Post #1 of 13 (1309 views)
Permalink
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--


aw at ice-sa

Mar 2, 2012, 2:02 AM

Post #2 of 13 (1284 views)
Permalink
Re: Terminating Child process Dynamically [In reply to]

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 at gmail

Mar 2, 2012, 2:23 AM

Post #3 of 13 (1266 views)
Permalink
Re: Terminating Child process Dynamically [In reply to]

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 [at] ice-sa> 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--


aw at ice-sa

Mar 2, 2012, 3:21 AM

Post #4 of 13 (1266 views)
Permalink
Re: Terminating Child process Dynamically [In reply to]

> On Fri, Mar 2, 2012 at 3:32 PM, André Warnier <aw [at] ice-sa> 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;
}


vv.lists at wanadoo

Mar 2, 2012, 9:51 AM

Post #5 of 13 (1266 views)
Permalink
Re: Terminating Child process Dynamically [In reply to]

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


perrin at elem

Mar 2, 2012, 10:49 AM

Post #6 of 13 (1279 views)
Permalink
Re: Terminating Child process Dynamically [In reply to]

On Fri, Mar 2, 2012 at 3:20 AM, Shibi Ns <shibi.ns [at] gmail> 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


shibi.ns at gmail

Mar 2, 2012, 11:04 AM

Post #7 of 13 (1273 views)
Permalink
Re: Terminating Child process Dynamically [In reply to]

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 [at] ice-sa> wrote:

> On Fri, Mar 2, 2012 at 3:32 PM, André Warnier <aw [at] ice-sa> 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--


davehodg at gmail

Mar 2, 2012, 4:20 PM

Post #8 of 13 (1271 views)
Permalink
Re: Terminating Child process Dynamically [In reply to]

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.


torsten.foertsch at gmx

Mar 7, 2012, 3:59 AM

Post #9 of 13 (1250 views)
Permalink
Re: Terminating Child process Dynamically [In reply to]

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


perrin at elem

Mar 7, 2012, 4:44 AM

Post #10 of 13 (1250 views)
Permalink
Re: Terminating Child process Dynamically [In reply to]

- Perrin
On Mar 7, 2012 7:00 AM, "Torsten Förtsch" <torsten.foertsch [at] gmx> 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
>


perrin at elem

Mar 7, 2012, 5:06 AM

Post #11 of 13 (1250 views)
Permalink
Re: Terminating Child process Dynamically [In reply to]

[.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 <torsten.foertsch [at] gmx>:
> 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


torsten.foertsch at gmx

Mar 7, 2012, 6:05 AM

Post #12 of 13 (1260 views)
Permalink
Re: Terminating Child process Dynamically [In reply to]

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


perrin at elem

Mar 7, 2012, 10:54 AM

Post #13 of 13 (1243 views)
Permalink
Re: Terminating Child process Dynamically [In reply to]

2012/3/7 Torsten Förtsch <torsten.foertsch [at] gmx>:
> 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

ModPerl modperl RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.