You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Philip M. Gollucci" <pg...@p6m7g8.com> on 2006/09/01 07:57:41 UTC
Re: Reloading .so files and .pm files
Ben Wilder wrote:
> Thanks Philip,
>
> Your advice is very helpful.
> you can guess whats coming next... running this under Mod_perl with 8
> 'StartServers', if i perform 8 requests with a particular $packageFileName
> and then attempt a different $packageFileName, Mod_perl will tell me that
> the package does not exist, because the 8 child processes all have a
> compiled version using the first $packageFileName that i specified and
> 'required'.
2.x example:
<Location /foo>
SetHandler modperl
PerlResponseHandler FOO
</Location>
package FOO;
#core
use strict;
use warnings FATAL => 'all'; no warnings qw(redefine);
use Carp;
#mp2
use Apache2::RequestRec ();
use Apache2::Const -compile => qw(OK);
use Apache2::Log ();
#libapreq
use APR::Request ();
use APR::Request::Apache2 ();
## Or this is already in PERL5INC some other way already
use lib qw(/path/to/lotsofpms);
sub handler {
my $r = shift;
my $req = APR::Request::Apache2->handle($r);
my $pkg = $req->param('pkg');
## VALIDATE $pkg VERY carefully for MALICOUS input!
## VALIDATE $pkg VERY carefully for MALICOUS input!
## VALIDATE $pkg VERY carefully for MALICOUS input!
## VALIDATE $pkg VERY carefully for MALICOUS input!
if (eval "require $pkg") {
## if this can fail or not exist, eval {} it
## or use UNIVERSAL::can()
$pkg->methodX(%args);
}
else {
$r->log_error("$pkg require failed\n")
}
return Apache2::Const::OK;
}
1;
Were it me, I would just have a 'use' statement for _ALL_ the files in your startup.pl
and in this file.
BECAUSE if you serve a requests for X of the Y packages you use the memory X, but its not shared with the 'require'
method. If you do the startup.pl/use thing, you still use the memory, but its shared.
This also answers your question, even if the child compiles stuff it will use the module you request everytime.
I'm guess you were using package/file scoped global vars before -- hence the caching problem.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ /
/ /|_/ / // /\ \/ /_/ / /__
/_/ /_/\_, /___/\___\_\___/
<___/
Re: Reloading .so files and .pm files
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
> ## Or this is already in PERL5INC some other way already
^^^ LIB
d'oh
Thats why you shouldn't code in thunderbird :)
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ /
/ /|_/ / // /\ \/ /_/ / /__
/_/ /_/\_, /___/\___\_\___/
<___/
RE: Reloading .so files and .pm files
Posted by Ben Wilder <be...@levexis.com>.
Hi Philip,
Just a note to thank you for taking the time to put together an example.
It's very much appreciated, and has taught me a fair bit. Your comments,
examples and suggestions have enabled me to create a working prototype.
I have a few long evenings with the Mod_perl docs I believe! :)
Regards,
Ben
-----Original Message-----
From: Philip M. Gollucci [mailto:pgollucci@p6m7g8.com]
Sent: 04 September 2006 10:01
To: ben.wilder@levexis.com
Cc: modperl@perl.apache.org
Subject: Re: Reloading .so files and .pm files
Ben Wilder wrote:
> 1) Your handler example is fantastic, however in my application I need to
> set the $pkg (the package to be dynamically included) from some logic in
> another script, so the process may go as follows:
> User request -> main script -> database call to get $pkg name - >
> dynamically call the package (as per your example).
See attached script.pl, Util.pm, and httpd.conf which will runs under the
ModPerl::Registry
handler (handlers are better though :)). The functionality is now in a
library and can be called
from anywhere.
Your variables need to be scoped to a FUNCTION via
'my' (or re-initialized properly on each request) This scoping is the
solution to your caching problem.
You need to read up on the "Core" modperl principles and what it actually
does with your code and how it caches it.
http://perl.apache.org/docs/1.0/guide/porting.html
While for 1.x the same principles apply to 2.x
> If my thinking is correct (and I'm a little new to Mod_perl!) the handler
> example you kindly wrote will be called when the /foo path is visited,
> however I will be needing to deliver this from a number of places (and
will
> not be able to rely on paths in the url) and would IDEALLY call the
dynamic
> functionality from within a script, rather than having it as a handler. Is
> there a way to do this and still not have the cache problem?
Thats correct, and see the attachments.
> 2) What is the best way to install the libapreq objects, can the same
> functionality be got through the Apache2 classes?
http://httpd.apache.org/apreq
download the lastest 2.08 un zip/tar and read the INSTALL file.
Apache2::* classes are wrapper around the APR::* classes (similar but not
always directly equivalent)
In general though both can get you what you want.
(attachments use Apache2::Request instead of APR::Request::Apache2)
http://httpd.apache.org/apreq/docs/libapreq2/modules.html
HTH
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ /
/ /|_/ / // /\ \/ /_/ / /__
/_/ /_/\_, /___/\___\_\___/
<___/
Re: Reloading .so files and .pm files
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Ben Wilder wrote:
> 1) Your handler example is fantastic, however in my application I need to
> set the $pkg (the package to be dynamically included) from some logic in
> another script, so the process may go as follows:
> User request -> main script -> database call to get $pkg name - >
> dynamically call the package (as per your example).
See attached script.pl, Util.pm, and httpd.conf which will runs under the ModPerl::Registry
handler (handlers are better though :)). The functionality is now in a library and can be called
from anywhere.
Your variables need to be scoped to a FUNCTION via
'my' (or re-initialized properly on each request) This scoping is the solution to your caching problem.
You need to read up on the "Core" modperl principles and what it actually does with your code and how it caches it.
http://perl.apache.org/docs/1.0/guide/porting.html
While for 1.x the same principles apply to 2.x
> If my thinking is correct (and I'm a little new to Mod_perl!) the handler
> example you kindly wrote will be called when the /foo path is visited,
> however I will be needing to deliver this from a number of places (and will
> not be able to rely on paths in the url) and would IDEALLY call the dynamic
> functionality from within a script, rather than having it as a handler. Is
> there a way to do this and still not have the cache problem?
Thats correct, and see the attachments.
> 2) What is the best way to install the libapreq objects, can the same
> functionality be got through the Apache2 classes?
http://httpd.apache.org/apreq
download the lastest 2.08 un zip/tar and read the INSTALL file.
Apache2::* classes are wrapper around the APR::* classes (similar but not always directly equivalent)
In general though both can get you what you want.
(attachments use Apache2::Request instead of APR::Request::Apache2)
http://httpd.apache.org/apreq/docs/libapreq2/modules.html
HTH
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ /
/ /|_/ / // /\ \/ /_/ / /__
/_/ /_/\_, /___/\___\_\___/
<___/
RE: Reloading .so files and .pm files
Posted by Ben Wilder <be...@levexis.com>.
Hi Philip,
Thanks again, your reply has been very useful. Just a few more questions if
I may though!
1) Your handler example is fantastic, however in my application I need to
set the $pkg (the package to be dynamically included) from some logic in
another script, so the process may go as follows:
User request -> main script -> database call to get $pkg name - >
dynamically call the package (as per your example).
If my thinking is correct (and I'm a little new to Mod_perl!) the handler
example you kindly wrote will be called when the /foo path is visited,
however I will be needing to deliver this from a number of places (and will
not be able to rely on paths in the url) and would IDEALLY call the dynamic
functionality from within a script, rather than having it as a handler. Is
there a way to do this and still not have the cache problem?
2) What is the best way to install the libapreq objects, can the same
functionality be got through the Apache2 classes?
3) Point taken with the startup.pl, I will (even though there may be many)
'use' the packages in both places, I can see the benefit of sharing as much
memory as possible, thanks for the advice.
Kind regards,
Ben
-----Original Message-----
From: Philip M. Gollucci [mailto:pgollucci@p6m7g8.com]
Sent: 01 September 2006 06:58
To: ben.wilder@levexis.com
Cc: modperl@perl.apache.org
Subject: Re: Reloading .so files and .pm files
Ben Wilder wrote:
> Thanks Philip,
>
> Your advice is very helpful.
> you can guess whats coming next... running this under Mod_perl with 8
> 'StartServers', if i perform 8 requests with a particular $packageFileName
> and then attempt a different $packageFileName, Mod_perl will tell me that
> the package does not exist, because the 8 child processes all have a
> compiled version using the first $packageFileName that i specified and
> 'required'.
2.x example:
<Location /foo>
SetHandler modperl
PerlResponseHandler FOO
</Location>
package FOO;
#core
use strict;
use warnings FATAL => 'all'; no warnings qw(redefine);
use Carp;
#mp2
use Apache2::RequestRec ();
use Apache2::Const -compile => qw(OK);
use Apache2::Log ();
#libapreq
use APR::Request ();
use APR::Request::Apache2 ();
## Or this is already in PERL5INC some other way already
use lib qw(/path/to/lotsofpms);
sub handler {
my $r = shift;
my $req = APR::Request::Apache2->handle($r);
my $pkg = $req->param('pkg');
## VALIDATE $pkg VERY carefully for MALICOUS input!
## VALIDATE $pkg VERY carefully for MALICOUS input!
## VALIDATE $pkg VERY carefully for MALICOUS input!
## VALIDATE $pkg VERY carefully for MALICOUS input!
if (eval "require $pkg") {
## if this can fail or not exist, eval {} it
## or use UNIVERSAL::can()
$pkg->methodX(%args);
}
else {
$r->log_error("$pkg require failed\n")
}
return Apache2::Const::OK;
}
1;
Were it me, I would just have a 'use' statement for _ALL_ the files in your
startup.pl
and in this file.
BECAUSE if you serve a requests for X of the Y packages you use the memory
X, but its not shared with the 'require'
method. If you do the startup.pl/use thing, you still use the memory, but
its shared.
This also answers your question, even if the child compiles stuff it will
use the module you request everytime.
I'm guess you were using package/file scoped global vars before -- hence the
caching problem.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ /
/ /|_/ / // /\ \/ /_/ / /__
/_/ /_/\_, /___/\___\_\___/
<___/