You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Tony van der Hoff <li...@vanderhoff.org> on 2007/06/29 19:24:15 UTC
Problems using Apache::Reload
I'm a bit of a newbie with respect to mod_perl, but with some perseverence,
I seem to have googled and hacked my way 'round most of it.
A couple of problems continue to dog me, though:
Because of constraints by my service provider, I'm running apache/1.3.37
with mod_perl/1.30 under linux on both my production and development
servers.
On my production server, I have no access to httpd/conf, so I have put the
various PERL init commands in .htaccess, thus:
Order allow,deny
Allow from all
Options Indexes FollowSymLinks MultiViews ExecCGI
DirectoryIndex index.pl
PerlModule Apache::Registry
PerlModule Apache::DBI
PerlInitHandler Apache::Reload
PerlSetVar ReloadAll Off
AddHandler perl-script .pl
PerlSendHeader On
PerlHandler Apache::Registry
Obviously, I want to keep as much similarity between my production and
development environments as I can, so I've done the same on the development
server.
The directory stucture is fairly deep, but ends up as a project directory,
containing the .htaccess, a bunch of .pl files, and a CCC subdirectory
containing a bunch of .pm modules.
This all seems to work well enough, except that on reload, PERL is unable to
find the .pm files which it wants to re-compile:
[Fri Jun 29 17:28:59 2007] [error] Can't locate CCC/MyDBI.pm in @INC (@INC
contains: /usr/lib/perl5/5.8.8/i386-linux /usr/lib/perl5/5.8.8
/usr/lib/perl5/site_perl/5.8.8/i386-linux /usr/lib/perl5/site_perl/5.8.8
/usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/i386-linux
/usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7
/usr/lib/perl5/vendor_perl/5.8.7/i386-linux /usr/lib/perl5/vendor_perl/5.8.6
/usr/lib/perl5/vendor_perl . /etc/apache1/ /etc/apache1/lib/perl) at
/usr/lib/perl5/site_perl/5.8.8/Apache/Reload.pm line 132.\n
The first time after an apache restart (on the development box) it works
fine; obviously it is able to find CCC in the project directory, but after I
edit one of the .pm files, it all goes titsup.
Note that "." is present in @INC, but I guess it refers to "/", because I
can work round this by placing a symlink to CCC in my root directory on the
development server, and in my chroot home on the production server.
Annoying, but not too desperate.
The second, and I assume associated, problem is that I get a shedload of
warnings each time the modules are recompiled, of the form:
[Fri Jun 29 17:41:05 2007] MyDBI.pm: Subroutine update_site_params redefined
at CCC/MyDBI.pm line 3659.
I assume this is because of the differing paths to the CCC directory. Now
this *is* a pain, because it masks any genuine errors, and it fills up the
apache error_log.
So, sorry to have rambled on a bit, but does anyone have any suggestions as
to how I can properly fix these problems, or tell me what I'm doing wrong.
Any advice will be very welcome.
Cheers,
--
Tony van der Hoff | mailto:tony@vanderhoff.org
Buckinghamshire, England
Re: Problems using Apache::Reload
Posted by Clinton Gormley <cl...@traveljury.com>.
Tony - There are lots of people using Registry successfully (in fact the
new Bugzilla uses Registry, if I remember correctly).
> Thank you, Jonathan, for your more detailed explanation. I have to say, I am
> extremely disappointed with my experience. I've used PHP for some years to
> create interactive web sites with some success, but having read about the
> significant performance boost available from mod_perl, I bit the bullet, and
> used PERL for the first time on my current project. Had I known then what I
> know now, I wouldn't have bothered :-(
>
> I don't even like the language much, but I'm sure that's a personal thing.
Give it time. I'm maintaining some PHP code, and all I want to do is
rewrite it in Perl.
>
> It looks then like I have two options:
> 1. abandon mod-perl and just use cgi.
> 2. move the project to a server over which I have full control.
>
> (1) rather defeats the object of using PERL, and I am loth to acknowledge
> defeat; (2) adds significant expense, and extra effort, to the project. Bah
> - what a mess!
I think that Jonathan is exaggerating the risks, and if you don't have
the luxury of running your own server then it is quite acceptable to use
these modules. See here for some points about the trade-offs that you
make :
http://search.cpan.org/~pgollucci/mod_perl-2.0.3/docs/api/Apache2/Reload.pod#Performance_Issues
I have little exposure to it, but from reading these lists over the last
decade, and reading the docs for Apache2::Reload, ModPerl::Registry etc,
I think that Registry is a perfectly usable product, with a couple of
gotchas.
I would welcome feedback on the experiences of others.
The biggest gotchas are:
* GLOBAL VARIABLES
In a CGI script, maybe you have:
our $var;
$var = 'xx' if $flag;
But because Registry scripts are persistent, variables that
haven't been properly intialiased, may contain data from
previous requests.
So instead write:
my $var;
OR
our $var = undef;
* CLOSURES : you can't do this:
my $var;
sub my_sub {
print $var;
}
... because Registry loads this script as:
sub handler {
my $var;
sub my_sub {
print $var
}
}
which will give you the warning: $var will not stay shared
Instead, do this:
sub my_sub {
my $var = shift;
print $var
OR
our $var = undef;
sub my_sub {
print $var;
* CHDIR
chdir is not thread safe, and cannot be relied upon, and the
current working dir is not reset for each call to a script.
Instead use absolute paths (plus use lib '/path');
* IMPORTING FROM MODULES / BEGIN/CHECK/END BLOCKS
If a Registry script imports subs/variables from a use'd module,
and the module is reloaded - the imported sub isn't updated. This
is because the 'use' statement executes on the first compile, and
not subsequently.
So instead of:
use MyModule qw(sub1 sub2);
Do:
require MyModule;
MyModule->import(qw(sub1 sub2));
Read more about the BEGIN/CHECK/END blocks issue here:
http://search.cpan.org/~pgollucci/mod_perl-2.0.3/docs/api/Apache2/Reload.pod#Caveats
Other than that, Registry works well. There will be edge cases where
Perl modules are doing some dark magic, which may have unexpected side
effects, but for the most part, it should all just work.
Clint
Re: Problems using Apache::Reload
Posted by Jonathan Vanasco <jv...@2xlp.com>.
You're comparing Apples to Rocks with php & mod_perl ( rocks was the
first non-fruit thing I could think of )
php has 3 main flavors - mod_php , php-cgi , php-cli
lets just look at mod_php and php-cgi
if you run perl and php through a fastcgi proxy , you're going to
get similar performance from an architecture standpoint. each
language will be a bit faster or slower depending on its strengh or
weakness in whatever you test, but the overall design of the systems
will be the same, and you won't see much of a difference.
mod_php and mod_perl sound kind of similar..
mod_php is sticking a php interpreter in apache , and using that to
process files
mod_perl is sticking a perl interpreter in apache , and using that
to process files ( it can script apache + integrate with hooks too )
but they behave a little differently because of the way they have
very different approaches in the way they handle memory - shared
memory, loading libraries, copy on write, etc
they also have slightly different architectures
most people use mod_perl in dedicated environments -- it achieves its
speed performance by compiling & caching code -- which eats up
memory. because code is handled with the package namespaces, people
generally don't run it in shared environments, as you provide
security from people overwriting namespaces can only happen by
consuming more memory to create isolated namespaces in the children.
some people here may disagree with me and chime in...
but i strongly advise not depending on mod_perl if you don't have
'root' access for apache. you're going to create a lot of headaches
for yourself, and you're only going to be able to experience a
limited subset of features & optimizations that are offered. as a
bad analogy, your experience with mod_perl is going to be like
driving a sportscar around in a crowded parkinglot - you're stuck
with a small speedlimit and you can't leave the lot and really see
whats under the hood.
if i were in your situation, i'd do the following:
1, try to get root access , so you can run/write handlers or
registry stuff that won't depend on reload
2, look into your options with running perl via fast-cgi
3, stick to php. drop apache, switch to nginx and run php via fast-
cgi , utilizing the APC cache ( or the eaccelerator one if its
working again )
a while back I benched a simple app in php & perl, using the phptal &
petal libraries:
20 r/s - mod_php / Apache
150 r/s/ - php-cgi / apc / nginx
200 r/s - mod_perl
the huge speed differences between nginx and mod_php was due to:
a- nginx is faster/more lightweight, tied up less resources than apache
b- apc cached the phptal templates & engines way better than the
standard php stat or whatever it does. i didn't bench rps under
apache using apc and not, but the generation time went from .7
seconds to .09 per page. it was a HUGE difference on that alone.
c- mp likely edged out php because perl is just kickass with text-
processing, which is primarily what i benched.
that said, if you don't like perl - don't use it. there are lots of
ways to improve your php performance.
i still use php -- we have a lot of micro-sites and templates that we
don't want to cache. running that stuff in php lets us easily
specify how much memory we want to limit that too , and keep it
isolated from our main perl servers. all of the db interaction on
that stuff is handled by requests to internal perl-servers which
return json objects. its really gives us the best of both worlds.
On Jul 1, 2007, at 4:47 AM, Tony van der Hoff wrote:
> On 30 Jun at 16:55 Jonathan Vanasco <jv...@2xlp.com> wrote in
> message
> <03...@2xlp.com>
>
> [snip]
>> assuming you're on a nix/bsd -- you need to be able to restart the
>> server.
>> if you can't , then you shouldn't be using mod_perl.
> [snip]
>
> Thank you, Jonathan, for your more detailed explanation. I have to
> say, I am
> extremely disappointed with my experience. I've used PHP for some
> years to
> create interactive web sites with some success, but having read
> about the
> significant performance boost available from mod_perl, I bit the
> bullet, and
> used PERL for the first time on my current project. Had I known
> then what I
> know now, I wouldn't have bothered :-(
>
> I don't even like the language much, but I'm sure that's a personal
> thing.
>
> It looks then like I have two options:
> 1. abandon mod-perl and just use cgi.
> 2. move the project to a server over which I have full control.
>
> (1) rather defeats the object of using PERL, and I am loth to
> acknowledge
> defeat; (2) adds significant expense, and extra effort, to the
> project. Bah
> - what a mess!
>
> Thanks again, Tony
>
> --
> Tony van der Hoff | mailto:tony@vanderhoff.org
> Buckinghamshire, England
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| CEO/Founder SyndiClick Networks
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| Founder/CTO/CVO
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
Re: Problems using Apache::Reload
Posted by Tony van der Hoff <li...@vanderhoff.org>.
On 30 Jun at 16:55 Jonathan Vanasco <jv...@2xlp.com> wrote in message
<03...@2xlp.com>
[snip]
> assuming you're on a nix/bsd -- you need to be able to restart the server.
> if you can't , then you shouldn't be using mod_perl.
[snip]
Thank you, Jonathan, for your more detailed explanation. I have to say, I am
extremely disappointed with my experience. I've used PHP for some years to
create interactive web sites with some success, but having read about the
significant performance boost available from mod_perl, I bit the bullet, and
used PERL for the first time on my current project. Had I known then what I
know now, I wouldn't have bothered :-(
I don't even like the language much, but I'm sure that's a personal thing.
It looks then like I have two options:
1. abandon mod-perl and just use cgi.
2. move the project to a server over which I have full control.
(1) rather defeats the object of using PERL, and I am loth to acknowledge
defeat; (2) adds significant expense, and extra effort, to the project. Bah
- what a mess!
Thanks again, Tony
--
Tony van der Hoff | mailto:tony@vanderhoff.org
Buckinghamshire, England
Re: Problems using Apache::Reload
Posted by Jonathan Vanasco <jv...@2xlp.com>.
On Jun 30, 2007, at 2:40 AM, Tony van der Hoff wrote:
>
> Well, it is my intention that the modules should be reloaded if
> they've
> changed; that's the whole point of using Apache::Reload, so I'm
> pleased it
> works. Presumably, if they haven't changed, the only performance
> hit is a
> stat to the file system, and then only on those modules which
> explicitly
> call Apache::Reload. I think I can live with that :)
Thats the intention of the devel environment. But aside from the
performance hit, reload doesn't work perfectly. some module changes
won't get picked up due to class override / superclass conflicts,
other changes will cause Reload to just crash your server. when
you're running reload, you're ideally having the stat and a clean
reload -- in practice you can get larger performance hits from the
stat being read wrong and tons of crashes.
> However, without the ability to restart the server, and short of
> renaming
> the files, how should I update my software? It won't happen much at
> the
> production end, but it will certainly happen. Shouting Never,
> Never, Never
> is all very well, and undoubtedly good advice, but it's a bit
> impractical
> without an alternative.
assuming you're on a nix/bsd -- you need to be able to restart the
server. if you can't , then you shouldn't be using mod_perl. see
if you can run apache on a port you can control, then proxypass to it.
mod_perl does a lot of performance/memory optimizations by using the
copy-on-write model for vars and caching compiled subs. when you
'reload' code, you're just redefining the subs... which means they
get unshared.
illustration
start parent-a
fork child-a child-a child-a
update code
reload
child-a child-a child-b
child-a child-b child-b
child-b child-b child-b
i'm not sure how reload affects the master-process memory-- but I
have a funny feeling that new children will spawn with the pre-update
code, then stat to the new code
> What are the other problems you refer to? I've been lurking on this
> list for
> some months, but have not seen anything mentioned, and Google
> doesn't throw
> up anything on the first few pages.
look back within the past 18-6 months. there was a lot of reload
talk then. not as much lately.
also, you should never do an apachectl restart/graceful.
you want to do a full apache stop, and then apache start. the
integrated restart command will essentially cause a memory leak ( its
not really leaking, but the memory isn't recycled/overwrriten -- so
your process will double on size the first restart, etc etc etc )
On Jun 30, 2007, at 6:13 AM, Clinton Gormley wrote:
> With regards using Apache::Reload in production, my understanding is
> that, while Apache::Reload is really useful for development, there are
> edge cases where things get messed up, and which require a stop-
> start to
> get them working again. And for this reason, we would not usually
> consider using this module in production.
its much less edge-cases than it is use-cases.
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| CEO/Founder SyndiClick Networks
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| Founder/CTO/CVO
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
Re: Problems using Apache::Reload
Posted by Tony van der Hoff <li...@vanderhoff.org>.
On 29 Jun at 21:47 Jonathan Vanasco <jv...@2xlp.com> wrote in message
<89...@2xlp.com>
>
> On Jun 29, 2007, at 4:09 PM, Tony van der Hoff wrote:
> > Well, thank you for that advice.
> >
> > Um, Why?
> >
> > How does that help solve my problems?
>
>
> Apache::Reload checks perl modules and *reloads* them on every hit if
> they've changed. It's essentially saying "hi, i'm running under a
> persistant environment , where code shouldn't be changing, but I'm going
> to take a performance hit each time". you get a perfomance hit AND you
> start to lose memory ( stuff goes from shared to unshared )
>
> it also performs very awkwardly and has been the cause of numerous
> problems on this list. its likely not the culprit of the problem you're
> seeing now, but it will be causing many issues down the road. its not
> meant for production, its geared for dev servers.
>
[snip]
Well, it is my intention that the modules should be reloaded if they've
changed; that's the whole point of using Apache::Reload, so I'm pleased it
works. Presumably, if they haven't changed, the only performance hit is a
stat to the file system, and then only on those modules which explicitly
call Apache::Reload. I think I can live with that :)
However, without the ability to restart the server, and short of renaming
the files, how should I update my software? It won't happen much at the
production end, but it will certainly happen. Shouting Never, Never, Never
is all very well, and undoubtedly good advice, but it's a bit impractical
without an alternative.
What are the other problems you refer to? I've been lurking on this list for
some months, but have not seen anything mentioned, and Google doesn't throw
up anything on the first few pages.
Anyway, this all pales into insignificance against the real problems which
started this thread; I'd really appreciate some pointers as to how to fix
those.
Cheers, Tony
--
Tony van der Hoff | mailto:tony@vanderhoff.org
Buckinghamshire, England
Re: Problems using Apache::Reload
Posted by Jonathan Vanasco <jv...@2xlp.com>.
On Jun 29, 2007, at 4:09 PM, Tony van der Hoff wrote:
> Well, thank you for that advice.
>
> Um, Why?
>
> How does that help solve my problems?
Apache::Reload checks perl modules and *reloads* them on every hit if
they've changed. It's essentially saying "hi, i'm running under a
persistant environment , where code shouldn't be changing, but I'm
going to take a performance hit each time". you get a perfomance hit
AND you start to lose memory ( stuff goes from shared to unshared )
it also performs very awkwardly and has been the cause of numerous
problems on this list. its likely not the culprit of the problem
you're seeing now, but it will be causing many issues down the road.
its not meant for production, its geared for dev servers.
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| CEO/Founder SyndiClick Networks
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| Founder/CTO/CVO
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
Re: Problems using Apache::Reload
Posted by Tony van der Hoff <li...@vanderhoff.org>.
On 29 Jun at 20:08 Jonathan Vanasco <jv...@2xlp.com> wrote in message
<E1...@2xlp.com>
>
> On Jun 29, 2007, at 1:24 PM, Tony van der Hoff wrote:
> > So, sorry to have rambled on a bit, but does anyone have any suggestions
> > as to how I can properly fix these problems, or tell me what I'm doing
> > wrong. Any advice will be very welcome.
>
> I don't have time to analyze your config, but
>
> you should NEVER run Apache::Reload in a production server.
>
> NEVER
>
> NEVER NEVER NEVER.
>
Well, thank you for that advice.
Um, Why?
How does that help solve my problems?
--
Tony van der Hoff | mailto:tony@vanderhoff.org
Buckinghamshire, England
Re: Problems using Apache::Reload
Posted by Jonathan Vanasco <jv...@2xlp.com>.
On Jun 29, 2007, at 1:24 PM, Tony van der Hoff wrote:
> So, sorry to have rambled on a bit, but does anyone have any
> suggestions as
> to how I can properly fix these problems, or tell me what I'm doing
> wrong.
> Any advice will be very welcome.
I don't have time to analyze your config, but
you should NEVER run Apache::Reload in a production server.
NEVER
NEVER NEVER NEVER.
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| CEO/Founder SyndiClick Networks
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| Founder/CTO/CVO
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
Re: Problems using Apache::Reload
Posted by Marcus J Coles <m....@asitis.co.uk>.
> Re a virtual server solution - I've been looking for one as well. Here
> are a few I've found (haven't tried them yet):
>
> http://order.1and1.co.uk/xml/order/VpsRoot?__frame=_top&__lf=Static
> http://www.spry.com/plesk-vps/
> http://www.vpslink.com/
>
fwiw : Since your based in the UK give these guys a try:
http://www.memset.com
I run a few m_p apps on their vps' and they are cheap enough to let you
dip your toe in the water
+ given that they haven't been bought out yet they still have that rare
commodity :
support by the same people that run the show
Marcus
PS I don't work for them !-)
Re: Problems using Apache::Reload
Posted by Perrin Harkins <pe...@elem.com>.
On 7/1/07, Clinton Gormley <cl...@traveljury.com> wrote:
> This is one of the gotchas I mentioned before: CHDIR.
>
> You can't rely on it. Something somewhere (maybe Registry itself) is
> changing the current dir, so '.' now refers to / rather than
> to /path/to/your/modules.
It's actually not that something is doing a chdir, but that Registry
is NOT doing one. In a CGI environment, the current directory is
always set to the directory where the script lives. Unfortunately,
this is not safe for a threaded environment, so Registry doesn't do it
by default.
A subclass of Registry that deals with this is included in the
mod_perl distribution. It's called ModPerl::RegistryPrefork. There's
more explanation here:
http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Registry___C_Apache__PerlRun__and_Friends
- Perrin
Re: Problems using Apache::Reload
Posted by Clinton Gormley <cl...@traveljury.com>.
> >
> > Apache::Registry already looks for changes to your scripts and
> reloads
> > them as necessary. So you shouldn't need to use both of them.
>
> Well, I agree it says that, but when I tried using Registry without
> Reload,
> it didn't seem to work, so I gave up, and used Reload, more-or-less
> successfully.
>
Registry checks whether your script has changed:
- eg cgi-bin/login.pl
But if login.pl contains 'use My::Module', it doesn't check for that
module, which is why you would need Apache::Reload as well.
> So, I would, for instance, have a .pl file which contains
> ...
> use lib "."; # I believe this is implicit, anyway.
> use CCC::MyDBI;
> ...
This is one of the gotchas I mentioned before: CHDIR.
You can't rely on it. Something somewhere (maybe Registry itself) is
changing the current dir, so '.' now refers to / rather than
to /path/to/your/modules.
Change that to : use lib '/path/to/your/modules'; and it should work.
Re a virtual server solution - I've been looking for one as well. Here
are a few I've found (haven't tried them yet):
http://order.1and1.co.uk/xml/order/VpsRoot?__frame=_top&__lf=Static
http://www.spry.com/plesk-vps/
http://www.vpslink.com/
Good luck. When you get to grips with these issues, you'll end up
loving Perl.
Clint
Re: Problems using Apache::Reload
Posted by Tony van der Hoff <li...@vanderhoff.org>.
On 30 Jun at 11:13 Clinton Gormley <clint@traveljury.com > wrote in message
<11...@getafix.traveljury.com>
Thanks, Clint, for your helpful reply.
> Disclaimer: I have never used Apache::Reload, but:
>
> Apache::Registry already looks for changes to your scripts and reloads
> them as necessary. So you shouldn't need to use both of them.
Well, I agree it says that, but when I tried using Registry without Reload,
it didn't seem to work, so I gave up, and used Reload, more-or-less
successfully.
[snip]
>
> Secondly, the problem of it not finding your modules - you need to add a :
> use lib '/path/to/my/modules'; somewhere early on, for instance in a
> startup.pl file that is included in your config, or in one of the first
> lines of your .pl files.
>
Yeah, well, startup.pl is out of the question if the httpd.conf is
unavailable, and the server can't be restarted.
My understanding is that adding the "use lib" line is certainly required,
but only takes effect on invocation of the .pl code. If the modules are
already cached, then they are not reloaded. So that's where Apache::Reload
comes in. Any registered modules are stat'ed, and reloaded as necessary
*before* the .pl code are executed, and therefore *before* any "use lib"
instructions are processed.
So, I would, for instance, have a .pl file which contains
...
use lib "."; # I believe this is implicit, anyway.
use CCC::MyDBI;
...
Then, if MyDBI.pm contains "use Apache::Reload" (because Apache::ReloadAll
is off), Apache::Reload then registers CCC::MyDBI when it is first compiled.
On subsequent invocations it will look for CCC::MyDBI in @INC. Now, as you
correctly say, I could make a permanent change to @INC in a startup.pl, but
let's agree that's out of the question.
It would appear, that CCC::MyDBI can't be found in @INC; and I can fix
things (in development) by putting a symlink to CCC/ in any one of the
directories which do appear in @INC, or, for that matter (both in
development and production) in my root. That works well enough, but my
puzzlement derived from seeing "." in @INC; which I had expected to refer to
the project directory, which containc CCC. Apparently not, and I was
wondering why not.
Personally I would have expected Apache::Reload to have registered the full
path to CCC, which would overcome this problem, but, as I find with so many
other things in PERL, "It don't work that way".
[snip]
> PERL5LIB=/home/httpd/perl/extra; export PERL5LIB
>
> in the script that starts Apache. Alternatively, you can set this
> environment variable in httpd.conf:
>
> PerlSetEnv PERL5LIB /home/httpd/perl/extra
>
Anything that can be set in a .htaccess file is OK, and using the PerlSetEnv
there seems to work. So that's another small step forward, much better than
the symlink in root.
[snip]
>
> With regards the redefined warnings, what about this:
>
> use strict; use warnings FATAL => 'all'; no warnings 'redefine';
>
Yay! that works, too. Thank you.
[snip]
> If you are not able to restart your server, then you need to rely on some
> sort of stat'ing mechanism: Registry for scripts, and Reload for modules.
> A lot of people use this setup successfully. Just be aware that there may
> be non-obvious issues.
>
I think that's the pragmatic approach. Abandoning mod_perl now goes against
the grain; I may have to invest in a VPS solution, but I'll see how things
go.
At least with your help, I have overcome the most immediate ugliness, for
which I'm truly grateful.
Thanks again, Tony
--
Tony van der Hoff | mailto:tony@vanderhoff.org
Buckinghamshire, England
Re: Problems using Apache::Reload
Posted by Clinton Gormley <cl...@traveljury.com>.
Disclaimer: I have never used Apache::Reload, but:
Apache::Registry already looks for changes to your scripts and reloads
them as necessary. So you shouldn't need to use both of them. However,
reading the docs for Apache2::Reload, it mentions using it at the same
time as Registry scripts, which I think refers to using reload for other
modules, rather than duplicating the effort for Registry scripts.
It says that you will have a problem if, in your Registry script, you
'use' another module. Updates to that module will not be noticed by
Registry. Instead, you should do an explicit 'require module;
import(...)'.
> The first time after an apache restart (on the development box) it works
> fine; obviously it is able to find CCC in the project directory, but after I
> edit one of the .pm files, it all goes titsup.
Secondly, the problem of it not finding your modules - you need to add
a : use lib '/path/to/my/modules'; somewhere early on, for instance in a
startup.pl file that is included in your config, or in one of the first
lines of your .pl files.
Actually, reading the Apache2::Reload docs:
Note that Apache2::Reload operates on the current context of @INC. Which
means, when called as a Perl*Handler it will not see @INC paths added or
removed by ModPerl::Registry scripts, as the value of @INC is saved on
server startup and restored to that value after each request. In other
words, if you want Apache2::Reload to work with modules that live in
custom @INC paths, you should modify @INC when the server is started.
Besides, 'use lib' in the startup script, you can also set the PERL5LIB
variable in the httpd's environment to include any non-standard 'lib'
directories that you choose. For example, to accomplish that you can
include a line:
PERL5LIB=/home/httpd/perl/extra; export PERL5LIB
in the script that starts Apache. Alternatively, you can set this
environment variable in httpd.conf:
PerlSetEnv PERL5LIB /home/httpd/perl/extra
>
> Note that "." is present in @INC, but I guess it refers to "/", because I
> can work round this by placing a symlink to CCC in my root directory on the
> development server, and in my chroot home on the production server.
> Annoying, but not too desperate.
>
> The second, and I assume associated, problem is that I get a shedload of
> warnings each time the modules are recompiled, of the form:
With regards the redefined warnings, what about this:
use strict;
use warnings FATAL => 'all';
no warnings 'redefine';
>>From the source for ModPerl::Registry:
# we try to develop so we reload ourselves without die'ing on the warning
no warnings qw(redefine); # XXX, this should go away in production!
It doesn't explain WHY they should go away in production, but I presume
that having the warnings means that you can spot a redefine that
SHOULDN'T have happened.
With regards using Apache::Reload in production, my understanding is
that, while Apache::Reload is really useful for development, there are
edge cases where things get messed up, and which require a stop-start to
get them working again. And for this reason, we would not usually
consider using this module in production.
If you are not able to restart your server, then you need to rely on
some sort of stat'ing mechanism: Registry for scripts, and Reload for
modules. A lot of people use this setup successfully. Just be aware
that there may be non-obvious issues.
Repeated disclaimer: I have never used either Registry or Reload, but
have a look at the docs for Apache2::Reload - it sheds more light on the
issues you've been having, and probably works in a similar way to
Apache::Reload.
good luck
Clint