Thanks Philip,
Your advice is very helpful.
I wonder whether you could help with another question ?
As a follow up to my post earlier today (same scenario):
I have a package that performs the following:
It is used to dynamically require a particular .pm (from a directory of
100s) and call a generic method (common to all the .pms in the directory)
Which .pm package it requires is based on user input.
--Code snippet--
#Create package name and file name
my $packageName = $packageSchema . $packageId;
my $packageFileName = $packageName . ".pm";
#Attempt to 'require' the file
eval{require $packageFileName} or print "package does not exist";
#Attempt to execute the method call
my $execString = "$packageName" . "::" .
"GenericMethod('$methodArguments')";
my $resultString = eval $execString;
--Code snippet--
Each .pm file that is dynamically 'required' has a .so counterpart (the .pm
was generated by SWIG and is used to bootstrap the shared object)
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'.
I appreciate that this is exactly what Mod_perl is supposed to do, but has
anyone overcome this or any similar problems (conditionally 'requiring' code
in Mod_perl), and could you offer me any advice?
Once again, Very grateful for any advice you may have!
Regards
Ben
-----Original Message-----
From: Philip M. Gollucci [mailto:[EMAIL PROTECTED]
Sent: 31 August 2006 09:44
To: [EMAIL PROTECTED]
Cc: modperl@perl.apache.org
Subject: Re: Reloading .so files and .pm files
Ben Wilder wrote:
> Question:
> What with the nature of the statistics I need to call from the compiled
> shared objects, I am recompiling the .so files about twice a day (as
> situations change). I need to update the .so files and their corresponding
> .pm module files.
>
> Does anyone have any suggestions as to how I could expire the old ones the
> Mod_perl processes would be using get Mod_perl to pick up the newly
updated
> .so and .pm files?
>
> I would have a directory of roughly 100 .so files and their corresponding
> .pm files (generated by SWIG) that would be dynamically 'required' by
> calling scripts, about half of these 100 shared objects would be
recompiled
> about twice a day!
>
> Any thoughts much appreciated!
It should be -- reloading the .pm file if it boostraps the XS component
normally should suffice
For 2.x:
PerlModule Apache2::Reload
PerlInitHandler Apache2::Reload
PerlSetVar ReloadAll Off
PerlSetVar ReloadModules "X::*"
#PerlSetVAr ReloadDebug On
X is the top-level package namespace for where your .pm files are.
If you have multiple directories that works too.
http://perl.apache.org/docs/2.0/user/coding/coding.html#Auto_Reloading_Modif
ied_Modules_with_Apache2__Reload
IF your builds are croned or even not, you could aways fire off a graceful
restart -- 2x a day isn't bad.
You're likely loosing a lot of memory "requiring" the modules at run-time
anyway, so its probably good you restart twice
a day -- unless you preload all of them at startup.
--
------------------------------------------------------------------------
Philip M. Gollucci ([EMAIL PROTECTED]) 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."
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ /
/ /|_/ / // /\ \/ /_/ / /__
/_/ /_/\_, /___/\___\_\___/
<___/
