You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Tim Esselens <ti...@gmail.com> on 2005/07/20 13:15:19 UTC
[mp2] lifetime of Apache2::RequestRec
Hi list,
I'm using mp2 (2.0.1) and have it configured like this:
-[httpd.conf]------------
PerlResponseHandler X;
-[X.pm]------------------
package X;
sub handler() {
$r = shift;
print STDERR \$r."\n";
}
When I look at the printout, I get (ex):
0x11111 [req 1 child 1]
0x11111 [req 1 child 2]
0x22222 [req 2 child 1]
0x22222 [req 2 child 2]
...
So I was wondering wether or not this is normal behaviour.
(The Apache2::RequestRec is only re-new()ed every n-hits,
n being the number of apache children)
And where I could find out more about why it's doing this.
--
kind regards,
Tim Esselens
Re: [mp2] lifetime of Apache2::RequestRec
Posted by Stas Bekman <st...@stason.org>.
Tim Esselens wrote:
> Malcolm J Harwood wrote:
>
>>>Ah, i see, but then my question remains, why is this location changed
>>>after n hits (n = # of apache children)
>
>>Just a stab in the dark:
>>If you have a completely round-robin series of hits (ie. each child is hit
>>once in order before any child is hit twice).
>>The initial setup is completely deterministic - all children start with
>>the same state as they are forked from the same process.
>>So in each child, the first allocation occurs at the same address.
>>Then second time around, it's allocated somewhere else. (And if all your
>>hits are completely deterministic and identical, then that location may be
>>the same in all children too).
>
> That might just be the case, because if I leave the apache running for a
> while (and probably pollute its memspace by hitting other pages I'm
> developing) the addresses of $r start to change in a more random fashion.
When debugging this kind of issues it's the best to run in a single server
mode (httpd -X).
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] lifetime of Apache2::RequestRec
Posted by Tim Esselens <ti...@gmail.com>.
Malcolm J Harwood wrote:
>> Ah, i see, but then my question remains, why is this location changed
>> after n hits (n = # of apache children)
> Just a stab in the dark:
> If you have a completely round-robin series of hits (ie. each child is hit
> once in order before any child is hit twice).
> The initial setup is completely deterministic - all children start with
> the same state as they are forked from the same process.
> So in each child, the first allocation occurs at the same address.
> Then second time around, it's allocated somewhere else. (And if all your
> hits are completely deterministic and identical, then that location may be
> the same in all children too).
That might just be the case, because if I leave the apache running for a
while (and probably pollute its memspace by hitting other pages I'm
developing) the addresses of $r start to change in a more random fashion.
--
kind regards,
Tim Esselens
Re: [mp2] lifetime of Apache2::RequestRec
Posted by Malcolm J Harwood <mj...@liminalflux.net>.
On Wednesday 20 July 2005 01:58 pm, Tim Esselens wrote:
> Tom Schindl wrote:
> >> You're right, I've should have printed $r, which yields:
> >>
> >> Apache2::RequestRec=SCALAR(0x9d44644) [first n times]
> >> Apache2::RequestRec=SCALAR(0x9d7e0a4)
> >> (n begin the number of apache children)
> >>
> >> Am I correct in assuming that the Apache2::RequestRec object is now
> >> sitting in 0x9d44644 or is that just the mem address of the scalar,
> >> which changes, but is still pointing to the same RequestRec.
> > No. For every Request a ***NEW*** Request object is created! It's only
> > the pointer to it is written to the same location (e.g. 0x9d44644) but
> > maybe I'm not correct here.
> Ah, i see, but then my question remains, why is this location changed after
> n hits (n = # of apache children)
Just a stab in the dark:
If you have a completely round-robin series of hits (ie. each child is hit
once in order before any child is hit twice).
The initial setup is completely deterministic - all children start with the
same state as they are forked from the same process.
So in each child, the first allocation occurs at the same address.
Then second time around, it's allocated somewhere else. (And if all your hits
are completely deterministic and identical, then that location may be the
same in all children too).
Re: [mp2] lifetime of Apache2::RequestRec
Posted by Tim Esselens <ti...@gmail.com>.
Tom Schindl wrote:
>> You're right, I've should have printed $r, which yields:
>>
>> Apache2::RequestRec=SCALAR(0x9d44644) [first n times]
>> Apache2::RequestRec=SCALAR(0x9d7e0a4)
>> (n begin the number of apache children)
>>
>> Am I correct in assuming that the Apache2::RequestRec object is now
>> sitting in 0x9d44644 or is that just the mem address of the scalar, which
>> changes, but is still pointing to the same RequestRec.
>
> No. For every Request a ***NEW*** Request object is created! It's only
> the pointer to it is written to the same location (e.g. 0x9d44644) but
> maybe I'm not correct here.
Ah, i see, but then my question remains, why is this location changed after
n hits (n = # of apache children)
> Where from do you know that the request is served from a different child
I've used $$ as you suggested, from that I know that apache hits its
children in a round robin fashion (at least when I'm the only one doing a
page reload)
> You have to also print the $$ if your are running in prefork mpm, if you
> are running in a threaded mpm I have no idea how to distinguish between
> the different threads although there surely exists a thread ID or
> something like this.
I'm running in prefork mpm mode, with $$ the result looks like this:
# code
handler () {
$r = shift;
print STDERR $$." ".$r."\n";
return OK;
}
# result
26687 Apache2::RequestRec=SCALAR(0x922937c)
26688 Apache2::RequestRec=SCALAR(0x922937c)
26690 Apache2::RequestRec=SCALAR(0x922937c)
26691 Apache2::RequestRec=SCALAR(0x922937c)
26694 Apache2::RequestRec=SCALAR(0x922937c)
26696 Apache2::RequestRec=SCALAR(0x922937c)
26698 Apache2::RequestRec=SCALAR(0x922937c)
26700 Apache2::RequestRec=SCALAR(0x922937c)
26702 Apache2::RequestRec=SCALAR(0x922937c)
26704 Apache2::RequestRec=SCALAR(0x922937c)
- my apache has 10 children at the moment
26687 Apache2::RequestRec=SCALAR(0x9193884)
- stays the same for another 9 hits, then changes again
> Tom
--
kind regards,
Tim Esselens
Re: [mp2] lifetime of Apache2::RequestRec
Posted by Tom Schindl <to...@gmx.at>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tim Esselens schrieb:
> Tom Schindl wrote:
>
>
>>Does this really make sense? You are printing the pointer of the pointer
>>to the apache request object.
>
>
> You're right, I've should have printed $r, which yields:
>
> Apache2::RequestRec=SCALAR(0x9d44644) [first n times]
> Apache2::RequestRec=SCALAR(0x9d7e0a4)
> (n begin the number of apache children)
>
> Am I correct in assuming that the Apache2::RequestRec object is now sitting
> in 0x9d44644 or is that just the mem address of the scalar, which changes,
> but is still pointing to the same RequestRec.
No. For every Request a ***NEW*** Request object is created! It's only
the pointer to it is written to the same location (e.g. 0x9d44644) but
maybe I'm not correct here.
Where from do you know that the request is served from a different child
at least the code you posted does show any about put about the child
handling the request apache does not rotate the children used:
- - 1. request => child 1
- - 2. request => child 2
- - 3. request => child 2
- - 4. request => child 4
You have to also print the $$ if your are running in prefork mpm, if you
are running in a threaded mpm I have no idea how to distinguish between
the different threads although there surely exists a thread ID or
something like this.
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC3kb7kVPeOFLgZFIRAuiUAJ9dl3zesEpV7aZMq0PsXSxtPXhV2wCcCYFd
ELOY+/wk1eW2uD3B+lP9Ecg=
=5+ty
-----END PGP SIGNATURE-----
Re: [mp2] lifetime of Apache2::RequestRec
Posted by Tim Esselens <ti...@gmail.com>.
Tom Schindl wrote:
> Does this really make sense? You are printing the pointer of the pointer
> to the apache request object.
You're right, I've should have printed $r, which yields:
Apache2::RequestRec=SCALAR(0x9d44644) [first n times]
Apache2::RequestRec=SCALAR(0x9d7e0a4)
(n begin the number of apache children)
Am I correct in assuming that the Apache2::RequestRec object is now sitting
in 0x9d44644 or is that just the mem address of the scalar, which changes,
but is still pointing to the same RequestRec.
Anyway, In both cases, my question still remains, howcome the handler stays
the same for all children once, and then changes to another memory
location? ie: I'm using Template::Magic, and if I do something like:
our $t = new Template::Magic(...);
handler () {
my $r = shift;
my %hash = ( x => 1 );
$r->print($t->nprint(... lookup => [\%hash] ...));
return OK;
}
I get an output with an Array and Hash reference in it (don't know why, but
if I use $r->print(Dumper($t->nprint(...))) I can see it's the %hash of
template associated variables). And this behaves quite the same way as I
described earlier, it seems like the Array and Hash are relocated (?) every
n-th hit.
The reason I started investigating this, is because Template::Magic uses a
cache, and I assumed this behaviour would not allow caching more then n
times, since the object is re-new()ed. (I was wrong though, $t stays the
same all the time until server restart, but it got me wondering why the
handler does sometimes seem to relocate)
ps: I've been tinkering way too much, and could be overseeing the simplest
things (like \$r in my previous message).
> Moreover as far as I know perl reuses space allocated space (hence it's
> not freed) that's why you should not use fileuploads with mod_perl.
I see, so it might not be such a good idea to use Cache::Cache or does
it's purge method really deallocate the memory?
> Tom
--
kind regards,
Tim
Re: [mp2] lifetime of Apache2::RequestRec
Posted by Tom Schindl <to...@gmx.at>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Does this really make sense? You are printing the pointer of the pointer
to the apache request object.
- -------------------8<-------------------
package Bla;
sub new {
bless {};
}
package main;
# $bla = new Bla();
$bli = new Bla();
print "" . (\$bli) . " => $bli\n";
- -------------------8<-------------------
Run this example in the shell and you'll also get the same output, then
uncomment and the object is create in new memory position.
Moreover as far as I know perl reuses space allocated space (hence it's
not freed) that's why you should not use fileuploads with mod_perl.
Tom
Tim Esselens schrieb:
> Hi list,
>
> I'm using mp2 (2.0.1) and have it configured like this:
>
> -[httpd.conf]------------
> PerlResponseHandler X;
>
> -[X.pm]------------------
> package X;
> sub handler() {
> $r = shift;
> print STDERR \$r."\n";
> }
>
> When I look at the printout, I get (ex):
> 0x11111 [req 1 child 1]
> 0x11111 [req 1 child 2]
> 0x22222 [req 2 child 1]
> 0x22222 [req 2 child 2]
> ...
>
> So I was wondering wether or not this is normal behaviour.
> (The Apache2::RequestRec is only re-new()ed every n-hits,
> n being the number of apache children)
> And where I could find out more about why it's doing this.
>
> --
> kind regards,
> Tim Esselens
>
>
>
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC3joJkVPeOFLgZFIRAuWyAJ90owybBbSG6uW/hDbcL/MZwIITBgCeP4Wu
9hHxQexnZmRzoXE9hKKJCag=
=/Rny
-----END PGP SIGNATURE-----