Re: Odd Reload Behavior
On Sat, 2003-08-16 at 01:46, Cory 'G' Watson wrote: %somehash = (); This declaration is outside of any subroutines. Okay, so your subs that refer to it are now closures. That could be part of the issue. If you make %somehash a real global, it might help. I re-attacked this problem by adding a caller() check in App, and it proved to me that App was indeed being loaded twice. Once by my startup.pl (use App ();), and _again_ by an eval. caller() couldn't point me to the spot of code that was doing this, other than telling me it was a 'require App;'. I started flipping switches and localized it to PerlFreshRestart being on. When I turn it off, the eval() happens _before_ my startup.pl use() and subsequence call to App-load(). Well, first of all, you're just asking for trouble if you turn on PerlFreshRestart. Don't do it. Do you hava anything like a PerlModule App in your httpd.conf? You haven't actually shown us your real conf, startup, or code, so I'm just guessing here. Are you no longer having problems now that you turned off PerlFreshRestart? - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
On Sat, 2003-08-16 at 01:46, Cory 'G' Watson wrote: Well, first of all, you're just asking for trouble if you turn on PerlFreshRestart. Don't do it. I forget why I added it. My (poor) memory seems to recall something from the Eagle book causing me to add it. I'd never seen the 'evil' document before this weekend. My Eagle book is at the office, and I don't recall reading about it in the new Horse book. Do you hava anything like a PerlModule App in your httpd.conf? You haven't actually shown us your real conf, startup, or code, so I'm just guessing here. No, I only had a 'use App;' in my startup. Are you no longer having problems now that you turned off PerlFreshRestart? The problem has since gone away. I accidentally only replied to Ged Haywood when I got the thing working. When I added a caller() to the top of my module, I saw the initial startup.pl use(), and then a later eval() that I couldn't track. When I turned OFF PerlFreshRestart, the order was reversed (eval() before startup.pl's use()) and my problem, of course, went away. I assumed from the beginning that this was something of my own doing, I just wanted to know why my ignorance was causing to happen. It seems that PerlFreshRestart causes some difference in the loading of my modules. -- Cory 'G' Watson http://www.loggerithim.org -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
On Sun, 2003-08-17 at 22:15, Cory 'G' Watson wrote:
No, I only had a 'use App;' in my startup.
Your startup comes before the virtual host sections then?
When I added a caller() to the top of my module, I saw the initial
startup.pl use(), and then a later eval() that I couldn't track. When I
turned OFF PerlFreshRestart, the order was reversed (eval() before
startup.pl's use()) and my problem, of course, went away.
I assumed from the beginning that this was something of my own doing, I
just wanted to know why my ignorance was causing to happen. It seems that
PerlFreshRestart causes some difference in the loading of my modules.
As I understand it, the only thing that PerlFreshRestart does is clear
%INC when you restart the sever (with a USR1 signal), kind of like this:
while (($k, $v) = each(%INC))
{
delete($INC{$k}); eval(require $k);
}
I don't know where that eval call would be coming from with PerlFreshRestart
off. That's why I was wondering if you had PerlModule call somewhere in
httpd.conf.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
On Friday, August 15, 2003, at 06:23 PM, Ged Haywood wrote:
Ignore syntax errors and lack of declarations, as I just threw that
together from memory
The guesswork would be a lot easier if it didn't involve so much
guesswork. :)
I think the root question of my email was lost in my poor explanation.
Basically, I have a module (which I called App) that has something like:
%somehash = ();
This declaration is outside of any subroutines. VirtualHosts then call
App-load(name, libdir) to fille $somehash{$name} with a hashref of
page objects. All logging led me to believe that this variable was
being properly populated, but when that variable was accessed (via
getApp($name)), %somehash was undef.
Silly mistakes aside, I was basically trying to create a 'global'
variable that was populated by a method call _after_ it was
require()ed. The problem comes from the module being loaded _twice_.
The second time, %somehash = () sets things back to undef, but
loadApp() is not called again.
My motive for questioning the list was to find out if Apache's 'will
this survive a SIGHUP' pass caused this behavior, or if it was
something else I was missing.
I re-attacked this problem by adding a caller() check in App, and it
proved to me that App was indeed being loaded twice. Once by my
startup.pl (use App ();), and _again_ by an eval. caller() couldn't
point me to the spot of code that was doing this, other than telling me
it was a 'require App;'. I started flipping switches and localized it
to PerlFreshRestart being on. When I turn it off, the eval() happens
_before_ my startup.pl use() and subsequence call to App-load().
So this long-winded explanation is for the archives, and also to get an
idea as to why this happens. Thanks! :)
Cory 'G' Watson
Cory 'G' Watson
http://www.loggerithim.org
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
Hi there, On Sat, 16 Aug 2003, Cory 'G' Watson wrote: started flipping switches and localized it to PerlFreshRestart being on. Have you read http://perl.apache.org/docs/1.0/guide/troubleshooting.html#Evil_things_might_happen_when_using_PerlFreshRestart When I turn it off, the eval() happens _before_ my startup.pl use() and subsequence call to App-load(). So is it working now? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Odd Reload Behavior
I've recently written some code that behaves in a way I don't understand. It's basically a Handler that works for more than one VirtualHost. For each VirtualHost that uses the Handler, a call is made to App-loadPages(). It crawls an accompanying lib directory and loads the pages into a hashref, which is then stored in a global hash inside App. Later, during requests, the Handler calls App-getPages(key), where key is a unique name for each virtual host. This _should_ return a hashref full of page objects, but it returns undef. Since the App module is pre-loaded (in startup.pl), and loadPages() fills the hash, shouldn't the Handler's calls to getPages(key) work? I know it can, because I had it working a couple weeks ago, but something has broken it. It looks as though this works during the first 'load' that Apache does, which I'm assuming is the phase that checks for errors. The second phase seems to cause my global hash to get undef'ed, even though the loadPages() method works properly. I can divulge more code if necessary, but perhaps someone can clue me into why this happens. Cory 'G' Watson http://www.loggerithim.org -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
Hi there, On Fri, 15 Aug 2003, Cory 'G' Watson wrote: It looks as though this works during the first 'load' that Apache does, which I'm assuming is the phase that checks for errors. The second phase seems to cause my global hash to get undef'ed, even though the loadPages() method works properly. I'm not entirely convinced of the explanation, but have you tried testing the value of $Apache::Server::ReStarting in the code that fills the hash? It's in the Guide. Your message was a bit cavalier about what's a hash and what's a hashref, are you sure you aren't just missing a dereference somewhere? Have you got 'use strict' and warnings on? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
On Friday, August 15, 2003, at 12:43 PM, Ged Haywood wrote:
I'm not entirely convinced of the explanation, but have you tried
testing the value of $Apache::Server::ReStarting in the code that
fills the hash? It's in the Guide.
I'm not convinced of it either. :)
This code _would_ run twice, so I can protect it using the variable you
specified. I didn't know it existed. List messages seem to say that
this shouldn't be used?
Your message was a bit cavalier about what's a hash and what's a
hashref, are you sure you aren't just missing a dereference somewhere?
Have you got 'use strict' and warnings on.
It's a difficult concept to relay without pasting a bunch of code.
-- App.pm:
package App;
my %pageobjs;
sub loadApp {
my $self = shift();
my $name = shift();
my $libdir = shift();
my %pages;
opendir(LIBDIR, $libdir);
while(there are files to check) {
# blah, if the file is a .pm, require and instantiate it into
$page
$pages{$pageObjectName} = $page;
closedir(LOBDIR);
$pageobjs{$name} = \%pages;
}
sub getPages {
my $self = shift();
my $name = shift();
return $pageobjs{$name};
}
-- startup.pl:
use App;
Sooo, using the above code, the VHost uses:
PerlVar app blah
Perl
App-loadApp(blah, /usr/local/blah/lib);
/Perl
And, inside the Handler:
my $app = $r-dir_config(app);
my $hashRefOfPageObjs = App-getPages($app);
And $hashRefOfPageObjs is always undef;
Ignore syntax errors and lack of declarations, as I just threw that
together from memory into the ol' MUA here. Does that make more sense?
I believe I had this working at one point, but something has caused it
go south. The double load I see (which you explained with your
Restarting tip) was suspect only because if I put code into App which
Data::Dumper's the hash, there is something in it, but it disappears
between the first load and the first request. It looks like Perl
sections are executed twice, but this shouldn't cause the variable to
go undefined.
Cory 'G' Watson
http://www.loggerithim.org
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Odd Reload Behavior
Hello again, On Fri, 15 Aug 2003, Cory 'G' Watson wrote: PerlVar app blah Perl App-loadApp(blah, /usr/local/blah/lib); /Perl [snip] Ignore syntax errors and lack of declarations, as I just threw that together from memory The guesswork would be a lot easier if it didn't involve so much guesswork. :) Have you read http://perl.apache.org/docs/1.0/guide/config.html#PerlSetVar_and_PerlAddVar and http://perl.apache.org/docs/1.0/guide/config.html#Apache_Configuration_in_Perl ? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Reload and INC path partialy working
Ugh! Not use to lists that reply to author. Okay to resay what I sent to Geoffrey. using the -I switch in the config file works, unlike the PerlSetEnv PERL5LIBGeoffrey Young [EMAIL PROTECTED] wrote: Here's my perl.conf (sourced by httpd.conf) start LoadModule perl_module modules/mod_perl.so PerlSetEnv PERL5LIB /home/bruce/public_html/ffball/myffon second thought, tryPerlSwitches -I/home/bruce/public_html/ffball/myfforPerlSwitches -Mlib=/home/bruce/public_html/ffball/myffinstead of PERL5LIB--Geoffwww.bluewolverine.com Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
Apache::Reload and INC path partialy working
I'm trying to do some development work with mod_perl and find restarting the server a pain. So I setup Apache::Reload, but it doesn't seem to want to see my local devel directory all the time.Here's my settingsApache/2.0.40mod_perl-1.99_7Linux 2.4.20-8 (RedHat9 I think)Here's my perl.conf (sourced by httpd.conf)startLoadModule perl_module modules/mod_perl.soPerlSetEnv PERL5LIB /home/bruce/public_html/ffball/myffPerlSetVar INC /home/bruce/public_html/ffball/myffPerlModule Apache2PerlModule Apache::ReloadPerlInitHandler Apache::ReloadPerlSetVar ReloadDebug On# PerlSetVar ReloadModules "FFMgr::*"# This will allow execution of mod_perl to compile your scripts to# subroutines which it will execute directly, avoiding the costly# compile process for most requests.#Alias /perl /var/www/perlDirectory /var/www/perl SetHandler perl-script PerlHandler ModPerl::Registry::handler PerlOptions +ParseHeaders Options +ExecCGI/DirectoryDirectory /home/bruce/public_html FilesMatch "\.(pl|pm|cgi)$" SetHandler perl-script PerlHandler ModPerl::Registry::handler PerlOptions +ParseHeaders Options +ExecCGI /FilesMatch/Directoryend---The PerlSetVar INC line was a futile test.Here's the problem. It seems that the reload module is finding the local modules okay as it shows up in the error_log as checking the mtime. But when they do change, it dies when it tries to reload them and says they aren't in the @INC path.So it's like it is half working.Has anyone else seen this problem and have a possible fix?Thanks-Brucewww.bluewolverine.com Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: Apache::Reload and INC path partialy working
Bruce Tennant wrote: I'm trying to do some development work with mod_perl and find restarting the server a pain. So I setup Apache::Reload, but it doesn't seem to want to see my local devel directory all the time. Here's my settings Apache/2.0.40 mod_perl-1.99_7 please upgrade to the latest CVS version and try again - 1.99_07 is very old. Linux 2.4.20-8 (RedHat9 I think) Here's my perl.conf (sourced by httpd.conf) start LoadModule perl_module modules/mod_perl.so PerlSetEnv PERL5LIB /home/bruce/public_html/ffball/myff Here's the problem. It seems that the reload module is finding the local modules okay as it shows up in the error_log as checking the mtime. But when they do change, it dies when it tries to reload them and says they aren't in the @INC path. ok. can you show us @INC before and after the reload attempt? I'm curious as to whether PERL5LIB is being properly added to @INC for the request time interpreters. also, does it fail if you reload modules that are not in @INC? for instance, try touching CGI.pm or something in your site_lib and watch the debug messages. So it's like it is half working. Has anyone ! else seen this problem and have a possible fix? we'll find a fix if we can isolate and reproduce the problem, don't worry :) --Geoff
Re: Apache::Reload and INC path partialy working
Here's my perl.conf (sourced by httpd.conf) start LoadModule perl_module modules/mod_perl.so PerlSetEnv PERL5LIB /home/bruce/public_html/ffball/myff on second thought, try PerlSwitches -I/home/bruce/public_html/ffball/myff or PerlSwitches -Mlib=/home/bruce/public_html/ffball/myff instead of PERL5LIB --Geoff
Fwd: Re: Apache::Reload and INC path partialy working
Forwarding message as I didn't realize I was missing the list. Geoffrey Young [EMAIL PROTECTED] wrote: Date: Tue, 12 Aug 2003 14:18:37 -0400From: Geoffrey Young <[EMAIL PROTECTED]>To: Bruce Tennant <[EMAIL PROTECTED]>Subject: Re: Apache::Reload and INC path partialy workingok, I'll take a look at this.please repost to the list, though, so others can help and your results are recorded.and no, there is no rpm package for the latest CVS version that I know about - you'll need to compile it yourself (which is easy, don't worry :)--GeoffBruce Tennant wrote: The INC is correct (it has the new path in it). But if I touch a file in the added directory, it detects the file as being changed (uses proper INC), but seems to not find it when it is trying to reload it (sees base INC). I tried another thing, use a startup.pl file, it seems to work 90% of the time. Sometimes when a file is changed or reloaded, one of the sub httpd process will say it knows nothing about the reloaded module. But I can work w/this as a hitting reload on the browser fixes this. Here's the INC when no module is changed: /home/bruce/public_html/ffball/myff /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache2 /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl . Here's the INC after I touched Apache/DBI.pm in site_perl and it was reloaded (seen in log) /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache2 /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 . It would seem it dropped the perl5lib line. Oh also, if I remove the "use lib" line in my top file, none of my local modules will load. I though the PERL5LIB was suppose to add to the base INC and make it so you didn't need to use "use lib". Maybe this is the root of the problem. But as I mentioned, if using a startup script w/PerlRequire, the reloads seem to work. Do you know if there's a new rpm package for mod-perl (RH9)? */Geoffrey Young <[EMAIL PROTECTED]>/* wrote: Bruce Tennant wrote: I'm trying to do some development work with mod_perl and find restarting the server a pain. So I setup Apache::Reload, but it doesn't seem to want to see my local devel directory all the time. Here's my settings Apache/2.0.40 mod_perl-1.99_7 please upgrade to the latest CVS version and try again - 1.99_07 is very old.Linux 2.4.20-8 (RedHat9 I think)Here's my perl.conf (sourced by httpd.conf) start LoadModule perl_module modules/mod_perl.so PerlSetEnv PERL5LIB /home/bruce/public_html/ffball/myffHere's the problem. It seems that the reload module is finding the local modules okay as it shows up in the error_log as checking the mtime. But when th! ey do change, it dies when it tries to reload them and says they aren't in the @INC path. ok. can you show us @INC before and after the reload attempt? I'm curious as to whether PERL5LIB is being properly added to @INC for the request time interpreters. also, does it fail if you reload modules that are not in @INC? for instance, try touching CGI.pm or something in your site_lib and watch the debug messages.So it's like it is half working. Has anyone ! else seen this problem and have a possible fix? we'll find a fix if we can isolate and reproduce the problem, don't worry :) --Geoffwww.bluewolverine.com Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design softwarewww.bluewolverine.com Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: Apache::Reload and INC path partialy working
Hi Folks Fascinating to see this on a non-Windows box. Reloading modules after they have been editied, eg httpd like so: PerlModule Apache::Reload PerlInitHandler Apache::Reload PerlSetVar ReloadAll Off PerlSetVar ReloadModules CGI CGI::Application ... Sweep::* works about 99% of the time under Win2K and XP. I've been assuming it's a Windows thing. Perhaps the problem lies deeper? Server Version: Apache/2.0.46 (Win32) mod_perl/1.99_10-dev Perl/v5.8.0 -- Ron Savage, [EMAIL PROTECTED] on 14/08/2003. Room EF 312 Deakin University, 221 Burwood Highway, Burwood, VIC 3125, Australia Phone: +61-3-9251 7067, Fax: +61-3-9251 7604 http://www.deakin.edu.au/~rons
[mp1] Apache::Reload questions...
I've been working with Apache::Reload and Registry and have been unable to get any cache flushing to work. (I've added debug messages in Registry to show cache use or reloading). I've tried this combination: (httpd.conf) PerlModule Apache::RegistryPerlModule Apache::StatusPerlInitHandler Apache::ReloadPerlSetVar ReloadAll On And also this: PerlModule Apache::RegistryPerlModule Apache::StatusPerlInitHandler Apache::ReloadPerlSetVar ReloadAll OnPerlSetVar ReloadTouchFile /tmp/reload_modules No dice. Any suggestions? Apache 1.3.27, mod-perl 1.27 is the config. Roger
Re: [mp1] Apache::Reload questions...
On Fri, 2003-08-01 at 11:10, Roger Davenport wrote: I've been working with Apache::Reload and Registry and have been unable to get any cache flushing to work. (I've added debug messages in Registry to show cache use or reloading). Can you tell us what you are trying to reload and how you know it is isn't happening? Keep in mind, Apache::Reload has nothing to do with reloading Registry scripts. That reloading is handled entirely within Registry itself. - Perrin
Fwd: Re: [MP2] Apache::Reload date bug
--- Original Message --- From: Stas Bekman [EMAIL PROTECTED] To: Ron Savage [EMAIL PROTECTED] Cc: Sent: Sat, 01 Mar 2003 12:47:39 +1100 Subject: Re: [MP2] Apache::Reload date bug Ron Savage wrote: On Tue, 25 Feb 2003 09:40:05 +1100, Stas Bekman wrote: Hi Stas Output when run as /perl/main.cgi. Only the first line is expected (by me.) Ie why does the text from OK down, appear? : -8- This is a string OK The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Thanx. This particular problem has been fixed. cool. please followup on the list. So others know as well. Oops. -- Cheers Ron Savage, [EMAIL PROTECTED] on 02/03/2003 http://savage.net.au/index.html
Re: [MP2] Apache::Reload date bug
On Wed, 26 Feb 2003 22:30:51 -0600 (CST), Randy Kobes wrote: On Thu, 27 Feb 2003, Ron Savage wrote: On Wed, 26 Feb 2003 09:23:39 +1100, Stas Bekman wrote: HI Randy The mod_perl 2 ppm package (for ActivePerl 8xx) at http://theoryx5.uwinnipeg.ca/ppms/ is updated periodically with a cvs build - as of tonight, it's current. Thanx. Now my dual-booter at work is working, I hope to try this tomorrow. It's 8pm here now. -- Cheers Ron Savage, [EMAIL PROTECTED] on 27/02/2003 http://savage.net.au/index.html
Re: [MP2] Apache::Reload date bug
On Wed, 26 Feb 2003 09:23:39 +1100, Stas Bekman wrote: Hi Stas Have you tried the current mod_perl cvs? No. Being usually a Windows (shudder) user, I wait for Randy to issue a build. Today I spent 4 hours failing to install Red Hat 6, Red Hat 8 and Mandrake 9 on a brand new Dell with a 82854G/GL video chip. I was aiming for a dual-boot system. Amazing :-(. -- Cheers Ron Savage, [EMAIL PROTECTED] on 27/02/2003 http://savage.net.au/index.html
Re: [MP2] Apache::Reload date bug
On Thu, 27 Feb 2003, Ron Savage wrote: On Wed, 26 Feb 2003 09:23:39 +1100, Stas Bekman wrote: Hi Stas Have you tried the current mod_perl cvs? No. Being usually a Windows (shudder) user, I wait for Randy to issue a build. The mod_perl 2 ppm package (for ActivePerl 8xx) at http://theoryx5.uwinnipeg.ca/ppms/ is updated periodically with a cvs build - as of tonight, it's current. -- best regards, randy
Re: [MP2] Apache::Reload date bug
Ron Savage wrote: On Tue, 25 Feb 2003 09:40:05 +1100, Stas Bekman wrote: And what your error_log says? Nothing is output to the error_log. Have you tried the current mod_perl cvs? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [MP2] Apache::Reload date bug
On Wed, 19 Feb 2003 10:04:02 +1100, Stas Bekman wrote:
Ron Savage wrote:
On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote:
Hi Folks
In endeavouring to reproduce this problem, I've encountered another:
main.cgi:
-8-
#!/usr/bin/perl
use strict;
use warnings;
use CGI;
use Dummy;
# --
my($title) = 'Test';
my($q) = CGI - new();
my($s) = Dummy - string();
print $q - header({type = 'text/html;charset=ISO-8859-1'}),
$q - start_html({title = $title}),
$q - h1({align = 'center'}, $s),
$q - end_html();
-8-
Dummy.pm (in /perl/site/lib/):
-8-
package Dummy;
sub string{'This is a string'}
1;
-8-
Output when run as /perl/main.cgi. Only the first line is expected
(by me.) Ie why does the text from OK down, appear? :
-8-
This is a string
OK
The server encountered an internal error or misconfiguration and was
unable to complete your request.
Please contact the server administrator, [EMAIL PROTECTED] and inform
them of the time the error occurred, and anything you might have done
that may have caused the error.
More information about this error may be available in the server
error log.
--
--
Apache/2.0.43 Server at 127.0.0.1 Port 80
-8-
The part of httpd.conf controlling /perl/. Note Dummy is not included
here, but the original module, which revealed the original bug, is:
8
IfModule mod_perl.c
PerlModule Apache::Reload
PerlInitHandler Apache::Reload
PerlSetVar ReloadAll Off
PerlSetVar ReloadModules CGI::Explorer DBIx::AdminEngine Monash::*
Sweep::*
#PerlSwitches -Mblib=C:\Apache2
PerlRequire C:/Apache2/conf/startup.pl
Alias /perl/ C:/Apache2/perl/
Location /perl
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options +ExecCGI
PerlOptions +ParseHeaders
Order deny,allow
Deny from all
Allow from 127.0.0.1
/Location
8
I'll keep working on the original problem.
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 24/02/2003
http://savage.net.au/index.html
Re: [MP2] Apache::Reload date bug
Ron Savage wrote:
On Wed, 19 Feb 2003 10:04:02 +1100, Stas Bekman wrote:
Ron Savage wrote:
On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote:
Hi Folks
In endeavouring to reproduce this problem, I've encountered another:
main.cgi:
-8-
#!/usr/bin/perl
use strict;
use warnings;
use CGI;
use Dummy;
# --
my($title) = 'Test';
my($q) = CGI - new();
my($s) = Dummy - string();
print $q - header({type = 'text/html;charset=ISO-8859-1'}),
$q - start_html({title = $title}),
$q - h1({align = 'center'}, $s),
$q - end_html();
-8-
Dummy.pm (in /perl/site/lib/):
-8-
package Dummy;
sub string{'This is a string'}
1;
-8-
Output when run as /perl/main.cgi. Only the first line is expected
(by me.) Ie why does the text from OK down, appear? :
-8-
This is a string
OK
The server encountered an internal error or misconfiguration and was
unable to complete your request.
Please contact the server administrator, [EMAIL PROTECTED] and inform
them of the time the error occurred, and anything you might have done
that may have caused the error.
More information about this error may be available in the server
error log.
And what your error_log says?
OK is part of the error message. I think I've fixed that in the cvs version.
See if you get any better with it.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [MP2] Apache::Reload date bug
On Tue, 25 Feb 2003 09:40:05 +1100, Stas Bekman wrote: And what your error_log says? Nothing is output to the error_log. -- Cheers Ron Savage, [EMAIL PROTECTED] on 25/02/2003 http://savage.net.au/index.html
Re: [MP2] Apache::Reload date bug
Ron Savage wrote: On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote: perl -le 'warn(foo\n)' You got the quotes wrong for MS Windows, so I ran it twice: C:\Backupperl -le warn(qq|foo\n|) foo C:\Backupperl -le 'warn(foo\n)' well, you've got the idea, right. Perhaps someone on win32 can try to debug the behavior that you saw. I can't reproduce it on my linux box. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [MP2] Apache::Reload date bug
On Wed, 19 Feb 2003, Stas Bekman wrote: Ron Savage wrote: On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote: perl -le 'warn(foo\n)' You got the quotes wrong for MS Windows, so I ran it twice: C:\Backupperl -le warn(qq|foo\n|) foo C:\Backupperl -le 'warn(foo\n)' well, you've got the idea, right. Perhaps someone on win32 can try to debug the behavior that you saw. I can't reproduce it on my linux box. With my ActivePerl 8xx compatible perl-5.8, sticking in a warn(foo\n); inside a simple handler that uses Apache::Reload just output foo in the error log, with no timestamp nor client reported, as expected. I'm wondering though if this is coming from one of the custom modules used - in the log === [Sun Feb 16 23:49:41 2003] -e: Apache::Reload: Can't locate C:/Perl/site/lib//CGI/Explorer.pm === the message from Apache::Reload: warn(Apache::Reload: Can't locate $file\n), next unless defined $mtime amd $mtime; has a '-e:' in front, suggesting perhaps that another module is contributing to this entry. Can you make up a stripped-down version that exhibits this behaviour? -- best regards, randy
Re: [MP2] Apache::Reload date bug
Randy Kobes wrote: On Wed, 19 Feb 2003, Stas Bekman wrote: Ron Savage wrote: On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote: perl -le 'warn(foo\n)' You got the quotes wrong for MS Windows, so I ran it twice: C:\Backupperl -le warn(qq|foo\n|) foo C:\Backupperl -le 'warn(foo\n)' well, you've got the idea, right. Perhaps someone on win32 can try to debug the behavior that you saw. I can't reproduce it on my linux box. With my ActivePerl 8xx compatible perl-5.8, sticking in a warn(foo\n); inside a simple handler that uses Apache::Reload just output foo in the error log, with no timestamp nor client reported, as expected. I'm wondering though if this is coming from one of the custom modules used - in the log === [Sun Feb 16 23:49:41 2003] -e: Apache::Reload: Can't locate C:/Perl/site/lib//CGI/Explorer.pm === the message from Apache::Reload: warn(Apache::Reload: Can't locate $file\n), next unless defined $mtime amd $mtime; has a '-e:' in front, suggesting perhaps that another module is contributing to this entry. Can you make up a stripped-down version that exhibits this behaviour? I thought of that too, but wasn't sure if this is something special to win32. Could it be that the logs get interleaved? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
mp2 heads up with Apache::Reload
For those who started working with mp2 and found themselves unable to use Apache::Reload for connection filters and protocol handlers, I'm happy to tell you that the cvs version now supports Apache::Reload in the PerlPreConnectionHandler phase, which happens as early as possible. The updated docs are here: http://perl.apache.org/docs/2.0/api/Apache/Reload.html Let us know if you experience any problems with it. And make sure to read: http://perl.apache.org/docs/2.0/user/handlers/protocols.html#PerlPreConnectionHandler for potential nuances... __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[MP2] Apache::Reload date bug
Folks I don't know if this an Apache problem, or a mod_perl problem. Apache::Reload outputs a UTC date rather than a local date, when it encounters an error. Here's an excerpt from my log. Notice how the dates go Sun, Mon, ..., Sun. [Sun Feb 16 18:31:25 2003] [error] [client 127.0.0.1] Execution of C:/Apache2/cgi-bin/test/test-path-info.cgi aborted due to compilation errors., referer: http://127.0.0.1/cgi-bin/test/test-path-info.cgi [Mon Feb 17 10:44:04 2003] [error] [client 127.0.0.1] Premature end of script headers: menu-process-module.cgi, referer: http://127.0.0.1/cgi-bin/menu-process-module.cgi [Mon Feb 17 10:44:04 2003] [error] [client 127.0.0.1] Can't locate Module/MakeDist.pm in @INC (@INC contains: C:/Perl/lib C:/Perl/site/lib .) at C:/Apache2/cgi-bin/menu-process-module.cgi line 15., referer: http://127.0.0.1/cgi-bin/menu-process-module.cgi [Mon Feb 17 10:44:04 2003] [error] [client 127.0.0.1] BEGIN failed--compilation aborted at C:/Apache2/cgi-bin/menu-process-module.cgi line 15., referer: http://127.0.0.1/cgi-bin/menu-process-module.cgi [Sun Feb 16 23:49:41 2003] -e: Apache::Reload: Can't locate C:/Perl/site/lib//CGI/Explorer.pm -- Cheers Ron Savage, [EMAIL PROTECTED] on 17/02/2003 http://savage.net.au/index.html
[mp2] Having to reload apache when perl modules change
Hi again group. A quick question (but this might not be the right place). If this is the wrong place to ask, please point me in the direction of the right place. I have a web app written using mod_perl2 and apache::ASP. When I change the code in a perl module, I have to restart apache to make the changes appear to all children. Is there a way of avoiding this - maybe with an apache directive - so that all modules are re-read by all children without a restart ? Thanks Richard
Re: [mp2] Having to reload apache when perl modules change
Richard Curtis wrote: Hi again group. A quick question (but this might not be the right place). If this is the wrong place to ask, please point me in the direction of the right place. you're in the right place, don't worry :) I have a web app written using mod_perl2 and apache::ASP. When I change the code in a perl module, I have to restart apache to make the changes appear to all children. Is there a way of avoiding this - maybe with an apache directive - so that all modules are re-read by all children without a restart ? Apache::Reload ships standard with mod_perl 2.0 and is pretty much the same as with 1.0. See that manpage or docs/api/mod_perl-2.0/Apache/Reload.pod for more details. HTH --Geoff
Re: Apache::Reload and @INC
Igor Vylusko wrote: in doc http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html declared that when using Apache::Reload I may define additional lib in httpd.conf: PerlSetEnv PERL5LIB /home/httpd/perl/extra But when I enable PerlInitHandler Apache::Reload in config all libs defined in PERL5LIB are gone away from @INC. I have Apache 1.3.27, mod_perl 1.27, Apache::Reload 0.07, perl 5.8.0 on RH7.2 and try PerlSetEnv PERL5LIB in main config section as well as in VirtualHost sections. I have bulk of VirtualHosts and would like make @INC different for each one(i.e. not use lib ... in startup.pl). SB It's not easy with mod_perl 1.0. The manpage is talking about changing SB @INC globally for the whole server. I usually do that with 'use lib' in SB startup.pl. I define PerlSetEnv PERL5LIB globaly for the whole server but PERL5LIB was stripped out from @INC anyway on enabling PerlInitHandler Apache::Reload in _any_ vhost. I am using PerlSetEnv PERL5LIB per vhost basis and it works fine for me without Apache::Reload. I can't reproduce what you see with Apache::Reload and I don't see anything in the code that mangles @INC. Though what I do see, is that if you define PERL5LIB outside a VirtualHost, it overrides any PERL5LIB defined inside all VirtualHosts, no matter if you use Apache::Reload or not. I don't remember if that's how it should be or whether it's a bug. Those who use vhosts can probably help rectify the issue here. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Reload - filtering include directories
Stas Bekman wrote: Harry Danilevsky wrote: I did send the patch to Matt couple of days ago, but haven't heard back yet. Matt is on vacation I suppose I can also brace myslef, add namespaces, and clean up my own code. That's a good idea. As for the versioning, if this patch could be useful in both mod_perl 1.* and 2.0, can it be applied to both distributions? I don't quite understand why installing Apache::Reload from CPAN will cause mod_perl2.0 to be installed, but I'll try to think some more about it. Because Apache::Reload is distributed on CPAN and is not a part of mod_perl 1.0. And a genetically modified version is included in mod_perl 2.0. The right solution is probably to make Apache::Reload a part of mod_perl 1.0 as well and kill the CPAN version, or simply have a higher number on it. So people won't need to install it manually. I've committed your patch to the Apache::Reload version distributed with mod_perl 2.0 (plus documented the new feature). I've no control over the mod_perl 1.0 version maintained by Matt. Thanks for the patch Harry. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Apache::Reload and @INC
Hi All, in doc http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html declared that when using Apache::Reload I may define additional lib in httpd.conf: PerlSetEnv PERL5LIB /home/httpd/perl/extra But when I enable PerlInitHandler Apache::Reload in config all libs defined in PERL5LIB are gone away from @INC. I have Apache 1.3.27, mod_perl 1.27, Apache::Reload 0.07, perl 5.8.0 on RH7.2 and try PerlSetEnv PERL5LIB in main config section as well as in VirtualHost sections. I have bulk of VirtualHosts and would like make @INC different for each one(i.e. not use lib ... in startup.pl). Has anybody run across this problem? If sowhat is my solution? Thanks a lot, Igor.
Re: Apache::Reload and @INC
Igor Vylusko wrote: Hi All, in doc http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html declared that when using Apache::Reload I may define additional lib in httpd.conf: PerlSetEnv PERL5LIB /home/httpd/perl/extra But when I enable PerlInitHandler Apache::Reload in config all libs defined in PERL5LIB are gone away from @INC. I have Apache 1.3.27, mod_perl 1.27, Apache::Reload 0.07, perl 5.8.0 on RH7.2 and try PerlSetEnv PERL5LIB in main config section as well as in VirtualHost sections. I have bulk of VirtualHosts and would like make @INC different for each one(i.e. not use lib ... in startup.pl). It's not easy with mod_perl 1.0. The manpage is talking about changing @INC globally for the whole server. I usually do that with 'use lib' in startup.pl. Has anybody run across this problem? If sowhat is my solution? There are several solutions, none of which is very helpful in production, since they either slow things down or may cause collisions when modules with the same names are loaded, see: http://perl.apache.org/docs/1.0/guide/config.html#Is_There_a_Way_to_Modify__INC_on_a_Per_Virtual_Host_or_Per_Location_Basis_ _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re[2]: Apache::Reload and @INC
in doc http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html declared that when using Apache::Reload I may define additional lib in httpd.conf: PerlSetEnv PERL5LIB /home/httpd/perl/extra But when I enable PerlInitHandler Apache::Reload in config all libs defined in PERL5LIB are gone away from @INC. I have Apache 1.3.27, mod_perl 1.27, Apache::Reload 0.07, perl 5.8.0 on RH7.2 and try PerlSetEnv PERL5LIB in main config section as well as in VirtualHost sections. I have bulk of VirtualHosts and would like make @INC different for each one(i.e. not use lib ... in startup.pl). SB It's not easy with mod_perl 1.0. The manpage is talking about changing SB @INC globally for the whole server. I usually do that with 'use lib' in SB startup.pl. I define PerlSetEnv PERL5LIB globaly for the whole server but PERL5LIB was stripped out from @INC anyway on enabling PerlInitHandler Apache::Reload in _any_ vhost. I am using PerlSetEnv PERL5LIB per vhost basis and it works fine for me without Apache::Reload. Has anybody run across this problem? If sowhat is my solution? SB There are several solutions, none of which is very helpful in SB production, since they either slow things down or may cause collisions SB when modules with the same names are loaded, see: SB http://perl.apache.org/docs/1.0/guide/config.html#Is_There_a_Way_to_Modify__INC_on_a_Per_Virtual_Host_or_Per_Location_Basis_ I would like just set PerlInitHandler Apache::Reload on several vhosts only for developing purposes and preserve everything else at that. Thanks for advice, Igor.
Re: Memory leak on reload when the 'Pg' driver is preloaded
KGM == Keith G Murphy [EMAIL PROTECTED] writes: KGM When using a modular mod_perl, I get a huge leak if I preload the 'Pg' KGM driver in my startup perl script thus: Hmmm. Interesting theory. I shall have to investigate it. I also see a multi-megabyte memory leak in my app when DBD::Pg is preloaded, but I didn't track it down to just that module. Does it happen for you for any perl module that loads another XS compiled (ie, .so) file in addition to the .pm file? I'm on FreeBSD. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Memory leak on reload when the 'Pg' driver is preloaded
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OK, it gets weirder. The following script produces the leak. If I
comment out the install_driver line, I get a big old segfault! Same
if I comment out the Apache::DBI line in addition. This works with
plain apache, or apache-ssl.
#!/usr/bin/perl
use strict;
use Apache::Status ();
use Apache::DBI ();
DBI-install_driver('Pg');
1; #return true value
I looked into it with the following setup:
apache 1.3.26-0woody1
libapache-mod-perl 1.27-2
postgresql 7.2.1-2woody2
There was a Test.pm module handling all requests for /. It opened a
connection to the database and fetched a couple of rows.
With DBI-install_driver('Pg'), the Apache processes stayed at 8.4 MB. I
bombarded the Apache with ApacheBench and multiple SIGUSR1 but I found
no memory leaks. The process sizes did not change.
If I comment it all out including the Apache::Status line, I get
neither the segfault or the leak. (Well, small leak, a few bytes).
Without the install_driver() in place, everything worked as well. The
Apache processes stayed at near 6 MB. No segfaults. No problems.
So the install_driver masks a bigger problem with Apache::Status?
That's just too weird. But true, I swear.
Is there anyone else out there with Debian stable w/
apache+libapache-mod-perl who can try to reproduce this simple case?
I'd really like either a confirmation or a counterexample. If the
latter, I'd chalk it up to a weirdness on my system (and probably not
even pursue it, since I've moved on to the static version). I'm
pursuing it this far so Dan J. might get some useful feedback.
I'm pretty tired at the moment, so there might have been something I
mislooked. I'll give it another look tomorrow. At work, where I don't
have any distractions :)
It's pretty odd, in my view, that the Apache processes which did not
preload the Pg driver were smaller.
Keith, could you post results to modperl list if people at debian-isp
come to a different (or to the same) solution. I'm not subscribed to
the list.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9rxEXnksV4Ys/z5gRAqlBAJ9xKgkCmCxsg8huo/C1N0uk2XKSowCgoCdr
FdyuRGCkZvDifk5fyqfOcdo=
=im3K
-END PGP SIGNATURE-
Re: Memory leak on reload when the 'Pg' driver is preloaded
Juha-Mikko Ahonen wrote:
I looked into it with the following setup:
apache 1.3.26-0woody1
libapache-mod-perl 1.27-2
postgresql 7.2.1-2woody2
There was a Test.pm module handling all requests for /. It opened a
connection to the database and fetched a couple of rows.
With DBI-install_driver('Pg'), the Apache processes stayed at 8.4 MB. I
bombarded the Apache with ApacheBench and multiple SIGUSR1 but I found
no memory leaks. The process sizes did not change.
The interesting thing I see here is that you are using a different
libapache-mod-perl version. I'm using the one from stable. I hesitate
to install yours (from unstable), since apt-get wants to upgrade all of
perl (a whole *bunch* of shit), and I'm not keen on the idea of
permanently tracking unstable with something as complex as Perl and its
dependents. I mean, crap, it even wants to upgrade libc6. Last time I
tried, downgrading libc6 was not fun. I'm guessing you might find it
difficult to downgrade as well, since you probably have Perl 5.8. Any
ideas?
I'm pretty tired at the moment, so there might have been something I
mislooked. I'll give it another look tomorrow. At work, where I don't
have any distractions :)
I appreciate you looking at this. But it's mainly for the maintainer at
this point...
It's pretty odd, in my view, that the Apache processes which did not
preload the Pg driver were smaller.
Why would that be odd? Seems intuitively right to me.
Keith, could you post results to modperl list if people at debian-isp
come to a different (or to the same) solution. I'm not subscribed to
the list.
Will do, for sure.
Memory leak on reload when the 'Pg' driver is preloaded
Since memory leaks seem to be the topic du jour, I wondered if anyone
else had seen this one:
When using a modular mod_perl, I get a huge leak if I preload the 'Pg'
driver in my startup perl script thus:
#!/usr/bin/perl
use strict;
use Apache::Status ();
use Apache::DBI ();
DBI-install_driver('Pg');
1; #return true value
The leak happens when you send SIGUSR1 to the parent. Every time you do
it, you get more memory eaten (multiple megabytes), both in the parent
and (new) children.
It happens with the stock apache-ssl that comes from Debian stable.
Could well be a Debian-specific problem.
Using Debian's static-mod_perled apache-perl eliminates the problem.
Re: Memory leak on reload when the 'Pg' driver is preloaded
Using Debian's static-mod_perled apache-perl eliminates the problem. Do you mean you are using the 'so' version that comes with Debian? You should be using the static build of apache/mod_perl
Re: Memory leak on reload when the 'Pg' driver is preloaded
Stathy G. Touloumis wrote: Using Debian's static-mod_perled apache-perl eliminates the problem. Do you mean you are using the 'so' version that comes with Debian? Yes, in the case that failed. The package is called 'libapache-mod-perl'. You should be using the static build of apache/mod_perl You're telling me. :-( By should, do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? Might it be related to the Perl-malloc problem cited here: http://apache.perl.org/docs/1.0/guide/install.html#When_DSO_can_be_Used If either of the above or true, seems like Debian needs to quit distributing libapache-mod-perl. Thanks.
Re: Memory leak on reload when the 'Pg' driver is preloaded
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 October 2002 20:25, Keith G. Murphy wrote: By should, do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? Yes. The problems with DSO mod_perl are well known. It works perfectly when build staticly into Apache, though. Install apache-perl package instead of apache and libapache-mod-perl. Everything works with it as it would on normal Apache. After migrating to apache-perl, remove the LoadModule for mod_perl from your Apache configuration. Might it be related to the Perl-malloc problem cited here: http://apache.perl.org/docs/1.0/guide/install.html#When_DSO_can_be_Us ed If either of the above or true, seems like Debian needs to quit distributing libapache-mod-perl. The problem is not Debian-related, so it won't justify removing the package from Debian. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9raVtnksV4Ys/z5gRAt+TAJwOZXcdnVNoLWLza7NU6eOpCOB+dQCdEliU VDvG6M+qI88/RN/jj7KsCC0= =0/Bl -END PGP SIGNATURE-
Re: Memory leak on reload when the 'Pg' driver is preloaded
Hi there, On Wed, 16 Oct 2002, Keith G. Murphy wrote: do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? It's not as bad as that. Significant improvements have been made in the reliability of mod_perl as DSO and nowadays there is much less discussion about it on this list. There are still one or two dusty corners but in general thesedays I'd say try it. If it doesn't seem to give you problems then stay with it. If at first you don't succeed, try again. Then give up. No sense being a damned fool about it. (Somebody remind me who said that:) 73, Ged.
Re: Memory leak on reload when the 'Pg' driver is preloaded
Ged Haywood wrote: Hi there, On Wed, 16 Oct 2002, Keith G. Murphy wrote: do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? It's not as bad as that. Significant improvements have been made in the reliability of mod_perl as DSO and nowadays there is much less discussion about it on this list. Are you sure it's not because 'most everyone has silently given up on it? There are still one or two dusty corners but in general thesedays I'd say try it. I had not expected Debian stable to be one of the dusty corners. But I did find, upon investigating the bug reports, that there were *very* old reports about memory leaks, etc., with libapache-mod-perl. My own bug report is now 47 days old, without apparent followup. If it doesn't seem to give you problems then stay with it. If at first you don't succeed, try again. Then give up. Actually, that is what I have done already, several months ago. Seeing several reports of memory leak problems in the list made me think: Hmmm, wonder if someone else has seen this?
Re: Memory leak on reload when the 'Pg' driver is preloaded
Juha-Mikko Ahonen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 October 2002 20:25, Keith G. Murphy wrote: By should, do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? Yes. The problems with DSO mod_perl are well known. It works perfectly when build staticly into Apache, though. Install apache-perl package instead of apache and libapache-mod-perl. Everything works with it as it would on normal Apache. After migrating to apache-perl, remove the LoadModule for mod_perl from your Apache configuration. I already have, months ago. Might it be related to the Perl-malloc problem cited here: http://apache.perl.org/docs/1.0/guide/install.html#When_DSO_can_be_Us ed If either of the above or true, seems like Debian needs to quit distributing libapache-mod-perl. The problem is not Debian-related, so it won't justify removing the package from Debian. Huh? I would think that would be a really good reason to yank it. If it were Debian-related, the maintainer could fix it and keep it.
RE: Memory leak on reload when the 'Pg' driver is preloaded
For what it is worth, we use a DSO mod_perl/apache that we compiled ourselves, on RedHat thought, that is very stable and does not have noticeable memory leaks and have been using it for over 3 years. Just thought I would throw that out there. -Original Message- From: Keith G. Murphy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 2:02 PM To: mod_perl Mailing List Subject: Re: Memory leak on reload when the 'Pg' driver is preloaded Ged Haywood wrote: Hi there, On Wed, 16 Oct 2002, Keith G. Murphy wrote: do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? It's not as bad as that. Significant improvements have been made in the reliability of mod_perl as DSO and nowadays there is much less discussion about it on this list. Are you sure it's not because 'most everyone has silently given up on it? There are still one or two dusty corners but in general thesedays I'd say try it. I had not expected Debian stable to be one of the dusty corners. But I did find, upon investigating the bug reports, that there were *very* old reports about memory leaks, etc., with libapache-mod-perl. My own bug report is now 47 days old, without apparent followup. If it doesn't seem to give you problems then stay with it. If at first you don't succeed, try again. Then give up. Actually, that is what I have done already, several months ago. Seeing several reports of memory leak problems in the list made me think: Hmmm, wonder if someone else has seen this?
Re: Memory leak on reload when the 'Pg' driver is preloaded
Hi there, On Wed, 16 Oct 2002, Keith G. Murphy wrote: Significant improvements have been made in the reliability of mod_perl as DSO and nowadays there is much less discussion about it on this list. Are you sure it's not because 'most everyone has silently given up on it? Yes, I'm sure. Red Hat comes with Apache prebuilt for DSO I believe. I have worked on contracts for a number of organizations which use DSO mod_perl in high volume environments (hundreds of thousands of users). There are still one or two dusty corners but in general thesedays I'd say try it. I had not expected Debian stable to be one of the dusty corners. What I meant was that some (perhaps slightly unusual in some way) configurations seem to give more problems than others. For example I think that servers using SSL have perhaps been prone to troubles, but it could just as easily be that the people who experienced the problems were not careful to follow what you might say are slightly more complex than usual build procedures. 73, Ged.
Re: Memory leak on reload when the 'Pg' driver is preloaded
Ged Haywood wrote: Hi there, On Wed, 16 Oct 2002, Keith G. Murphy wrote: Significant improvements have been made in the reliability of mod_perl as DSO and nowadays there is much less discussion about it on this list. Are you sure it's not because 'most everyone has silently given up on it? Yes, I'm sure. Red Hat comes with Apache prebuilt for DSO I believe. I have worked on contracts for a number of organizations which use DSO mod_perl in high volume environments (hundreds of thousands of users). Then I take your word for it. (My question was sincere, not argumentative, by the way). There are still one or two dusty corners but in general thesedays I'd say try it. I had not expected Debian stable to be one of the dusty corners. What I meant was that some (perhaps slightly unusual in some way) configurations seem to give more problems than others. For example I think that servers using SSL have perhaps been prone to troubles, but it could just as easily be that the people who experienced the problems were not careful to follow what you might say are slightly more complex than usual build procedures. Hmmm. In my case, I replicated the problem with Debian's plain vanilla Apache as well, for the very purpose of simplification. So SSL does not seem to be involved.
Re: Memory leak on reload when the 'Pg' driver is preloaded
On Wed, Oct 16, 2002 at 02:01:33PM -0500, Keith G. Murphy wrote: Ged Haywood wrote: Hi there, On Wed, 16 Oct 2002, Keith G. Murphy wrote: do you mean that the problems with the loadable module overall are so well-known that no one in his right mind should ever use it? It's not as bad as that. Significant improvements have been made in the reliability of mod_perl as DSO and nowadays there is much less discussion about it on this list. Are you sure it's not because 'most everyone has silently given up on it? There are still one or two dusty corners but in general thesedays I'd say try it. I had not expected Debian stable to be one of the dusty corners. But I did find, upon investigating the bug reports, that there were *very* old reports about memory leaks, etc., with libapache-mod-perl. My own bug report is now 47 days old, without apparent followup. That's because I'm having an attack of real life. I haven't had time to look at my Debian bug reports in a month or so now. I don't know why the DSO is leaking in a case when the static module isn't, but it should be fixable; I just need to find five or six hours to sit down with it. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Memory leak on reload when the 'Pg' driver is preloaded
Daniel Jacobowitz wrote: On Wed, Oct 16, 2002 at 02:01:33PM -0500, Keith G. Murphy wrote: My own bug report is now 47 days old, without apparent followup. Hmmm, I probably should not have posted that. Sounds like a major whine. That's because I'm having an attack of real life. I haven't had time to look at my Debian bug reports in a month or so now. I don't know why the DSO is leaking in a case when the static module isn't, but it should be fixable; I just need to find five or six hours to sit down with it. Thanks, Dan, this really wasn't meant to be a slam-the-developer session. I really, *really* appreciate all the work you've done already. Now I feel tacky. :-( It's not like it was an obvious problem: I only got the DSO to leak when loading the Pg driver. That's pretty obscure.
Re: Memory leak on reload when the 'Pg' driver is preloaded
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 16 October 2002 22:52, Keith G. Murphy wrote:
It's not like it was an obvious problem: I only got the DSO to leak
when loading the Pg driver. That's pretty obscure.
Have you tried to connect() without loading the Pg driver first? E.g.
$dbh = DBI-connect('dbi:Pg:dbname=foo;host=bar', 'user', 'pass');
It would help eliminate if the leak is caused by your startup script. If
it is, it may be the DBI module that's leaking memory.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9rcZ5nksV4Ys/z5gRAjBQAJwKOUuu4B14yLe1msSNekI0mnPvdACdFMOe
TFLM0arS4L177Y+OuJMAUgM=
=GsvK
-END PGP SIGNATURE-
Re: Memory leak on reload when the 'Pg' driver is preloaded
[debian-isp readers, to recap, I'm trying to confirm a
memory-leak/segfault problem with Debian stable plus apache(-ssl) plus
libapache-mod-perl. The memory leak happens upon
/etc/init.d/apache(-ssl) reload. You can see my startup script and my
other comments below.]
Juha-Mikko Ahonen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 16 October 2002 22:52, Keith G. Murphy wrote:
It's not like it was an obvious problem: I only got the DSO to leak
when loading the Pg driver. That's pretty obscure.
Have you tried to connect() without loading the Pg driver first? E.g.
$dbh = DBI-connect('dbi:Pg:dbname=foo;host=bar', 'user', 'pass');
It would help eliminate if the leak is caused by your startup script. If
it is, it may be the DBI module that's leaking memory.
OK, it gets weirder. The following script produces the leak. If I
comment out the install_driver line, I get a big old segfault! Same if
I comment out the Apache::DBI line in addition. This works with plain
apache, or apache-ssl.
#!/usr/bin/perl
use strict;
use Apache::Status ();
use Apache::DBI ();
DBI-install_driver('Pg');
1; #return true value
If I comment it all out including the Apache::Status line, I get neither
the segfault or the leak. (Well, small leak, a few bytes).
So the install_driver masks a bigger problem with Apache::Status?
That's just too weird. But true, I swear.
Is there anyone else out there with Debian stable w/
apache+libapache-mod-perl who can try to reproduce this simple case?
I'd really like either a confirmation or a counterexample. If the
latter, I'd chalk it up to a weirdness on my system (and probably not
even pursue it, since I've moved on to the static version). I'm
pursuing it this far so Dan J. might get some useful feedback.
I've submitted this to debian-isp as well; maybe someone there can try it.
Apache::Reload - patch - fixes problems with using dynamic @INC
I started using a dynamic INC (set up in a TransHandler), and discovered
that Apache::Reload (v0.07) was not doing its job correctly in that case.
Note, changing INC in a transhandler won't have the desired Apache::Reload
effects unless the PerlInitHandler for Apache::Reload is placed in a
Location section of httpd.conf.
The following patch corrects this, though it adds a few extra stat() calls
if the module is found at the end of INC instead of near the beginning (as
mine are). You could make this behavior an optional one for strange folks
like me :). Oh, I just added that to the patch manually:
PerlSetVar ReloadDynamicInc 1
...will enable this INC-scanning behavior. I think I hacked the patch
correctly :)
Note, if a module is loaded with one INC, then on a subsequent request,
INC changes such that the module would be not-found, the module is not
removed from memory. If you do that and use it from a script (served when
INC doesn't have the module), you'll get erratic behavior - it'll work fine
sometimes and error out other times. So don't do that., as a wise man
said. Instead, make sure INC always has the right libs for your script -
test from a freshly-started server to be sure.
Separate from this strange Dynamic-@INC use case, there's another bug in the
release version of the module: if you moved a module from one INC dir to
another, the INC loop at the top of handler() would not find the file, as
it was looking for inc-dir/full-path-name instead of
inc-dir/relative-path-name. This patch should fix this too, whether
ReloadDynamicInc is used or not.
I haven't tested this with wildcard settings or ReloadAll.
Enjoy,
Randy
--- Reload.pm Sat Oct 12 16:22:02 2002
+++ Reload.pm.new Sat Oct 12 17:08:07 2002
-108,35 +108,40
while (my($key, $file) = each %Apache::Reload::INCS) {
local $^W;
warn Apache::Reload: Checking mtime of $key\n if $DEBUG;
my $mtime = (stat $file)[9];
-unless (defined($mtime) $mtime) {
-for (INC) {
-$mtime = (stat $_/$file)[9];
-last if defined($mtime) $mtime;
-}
-}
+
+my $found = $file;
+if( $r-dir_config(ReloadDynamicInc) || !$mtime ) {
+# seek out the file in INC.
+my $mt;
+for (INC) {
+$mt = (stat $_/$key)[9];
+$mtime = $mt, $found = $_/$key, last if defined($mt)
$mt;
+}
+}
+
warn(Apache::Reload: Can't locate $file\n),next
unless defined $mtime and $mtime;
unless (defined $Stat{$file}) {
$Stat{$file} = $^T;
}
-if ($mtime $Stat{$file}) {
+if( $found ne $file || $mtime $Stat{$file} ) {
delete $INC{$key};
if (my $symref = $UndefFields{$key}) {
#warn undeffing fields\n;
no strict 'refs';
undef %{$symref};
Apache::Reload -- can't locate main.pm?
I've been successfully using Apache::Reload for a few weeks now. However, I installed it on my home development system, and I'm getting this error when accessing a module that contains 'use Apache::Reload': [Mon Aug 26 09:59:12 2002] [error] Can't locate main.pm in INC (INC contains: ... at /home/miller/lib/perl5/site_perl/5.6.1/Apache/Reload.pm line 132. (yes, I install some modules under my own root tree - it keeps the base distribution nice and clean) What's main.pm, and why can't Apache::Reload find it? I've searched the archives, but have had little success in finding anything interesting. Apache1.3.26, mod_perl 1.26. Cheers! -klm.
Re: Apache::Reload -- can't locate main.pm?
* Ken Miller [EMAIL PROTECTED] [2002-08-26 12:03]: What's main.pm, and why can't Apache::Reload find it? I've searched the archives, but have had little success in finding anything interesting. Run find $dir -name 'main.pm' -print For each dir in @INC, and see what comes up. (darren) -- What the imagination siezes as beauty must be truth--whether it existed before on not. -- John Keats, Woman When I Behold Thee
Re: Apache::Reload -- can't locate main.pm?
Ken Miller wrote: I've been successfully using Apache::Reload for a few weeks now. However, I installed it on my home development system, and I'm getting this error when accessing a module that contains 'use Apache::Reload': [Mon Aug 26 09:59:12 2002] [error] Can't locate main.pm in @INC (@INC contains: ... at /home/miller/lib/perl5/site_perl/5.6.1/Apache/Reload.pm line 132. (yes, I install some modules under my own root tree - it keeps the base distribution nice and clean) What's main.pm, and why can't Apache::Reload find it? I've searched the archives, but have had little success in finding anything interesting. Apache1.3.26, mod_perl 1.26. In addition to Darren's reply, this explains what happens: http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html#Description says: Note that Apache::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 Apache::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 Apache::Reload to work with modules that live in custom @INC paths, you should modify @INC when the server is started. - __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Reload - filtering include directories
[...] Anyway, I decided to add another directive to Apache::Reload PerlSetVar ReloadDirectories /site/lib /usr/local/apache/conf Apache::Reload allows you to define which modules to reload using the patterns like so: PerlSetVar ReloadAll Off PerlSetVar ReloadModules Apache::* My::* Is there any reason why you cannot use this approach? I've no objection to your proposal, just wondering whether the existing features can be used instead. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Reload - filtering include directories
Two reasons : 1. My site-specific modules don't necessarily have a common namespace (or even several namespaces); they just all live in /site/lib. Without a ReloadDirectories-like filter every time I add another module, say, /site/lib/Reports.pm I'll need to add Reports to ReloadModules, and restart the server. 2. Much more obscure, related to HTML::Mason. As I mentioned in my post: In Mason components are precompiled and cached, so that perl code doesn't have to be re-parsed for every request. The cached files are require(d), and they end up in %INC. It appears from ReloadDebug's output that those cached files are being checked by Apache::Reload, and if they have been modified - they'll be reloaded. The problem is, if the code has a syntax error, that error will occur when Apache::Reload re-require()s that file, and the error message will be printed to a log file, not to the browser - which is what Mason would do. So your browser will simply tell you that 'Internal error has occurred' ReloadDirectories will simply ignore them, and let Mason deal with modified files. Am I still missing something ? Harry Danilevsky [EMAIL PROTECTED] Stas Bekman wrote: [...] Anyway, I decided to add another directive to Apache::Reload PerlSetVar ReloadDirectories /site/lib /usr/local/apache/conf Apache::Reload allows you to define which modules to reload using the patterns like so: PerlSetVar ReloadAll Off PerlSetVar ReloadModules Apache::* My::* Is there any reason why you cannot use this approach? I've no objection to your proposal, just wondering whether the existing features can be used instead. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Reload - filtering include directories
Harry Danilevsky wrote: Two reasons : 1. My site-specific modules don't necessarily have a common namespace (or even several namespaces); they just all live in /site/lib. Without a ReloadDirectories-like filter every time I add another module, say, /site/lib/Reports.pm I'll need to add Reports to ReloadModules, and restart the server. That's the thing. It's a good idea to alway use some prefix package name in all your modules, to avoid future clashes with other modules. And it automatically solves your problem with Apache::Reload. 2. Much more obscure, related to HTML::Mason. As I mentioned in my post: In Mason components are precompiled and cached, so that perl code doesn't have to be re-parsed for every request. The cached files are require(d), and they end up in %INC. It appears from ReloadDebug's output that those cached files are being checked by Apache::Reload, and if they have been modified - they'll be reloaded. The problem is, if the code has a syntax error, that error will occur when Apache::Reload re-require()s that file, and the error message will be printed to a log file, not to the browser - which is what Mason would do. So your browser will simply tell you that 'Internal error has occurred' ReloadDirectories will simply ignore them, and let Mason deal with modified files. If you tell Apache::Reload to look only at certain namespaces, this problem doesn't exist anymore. Am I still missing something ? Harry Danilevsky [EMAIL PROTECTED] Stas Bekman wrote: [...] Anyway, I decided to add another directive to Apache::Reload PerlSetVar ReloadDirectories /site/lib /usr/local/apache/conf Apache::Reload allows you to define which modules to reload using the patterns like so: PerlSetVar ReloadAll Off PerlSetVar ReloadModules Apache::* My::* Is there any reason why you cannot use this approach? I've no objection to your proposal, just wondering whether the existing features can be used instead. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Reload - filtering include directories
I certainly agree with attaching a common prefix to a library, but what if I am already dealing with a bunch of modules written without prefix, and enough application code using those packages ? I suppose I could change the code, or alias names in symbol table, or do some other trick; I just figured that one extra directive, plus one patched line was a cheap solution to my problems. I guess if nobody else sees any value in it, I'll just keep the private patched version for myself :-) Stas Bekman wrote: Harry Danilevsky wrote: Two reasons : 1. My site-specific modules don't necessarily have a common namespace (or even several namespaces); they just all live in /site/lib. Without a ReloadDirectories-like filter every time I add another module, say, /site/lib/Reports.pm I'll need to add Reports to ReloadModules, and restart the server. That's the thing. It's a good idea to alway use some prefix package name in all your modules, to avoid future clashes with other modules. And it automatically solves your problem with Apache::Reload. 2. Much more obscure, related to HTML::Mason. As I mentioned in my post: In Mason components are precompiled and cached, so that perl code doesn't have to be re-parsed for every request. The cached files are require(d), and they end up in %INC. It appears from ReloadDebug's output that those cached files are being checked by Apache::Reload, and if they have been modified - they'll be reloaded. The problem is, if the code has a syntax error, that error will occur when Apache::Reload re-require()s that file, and the error message will be printed to a log file, not to the browser - which is what Mason would do. So your browser will simply tell you that 'Internal error has occurred' ReloadDirectories will simply ignore them, and let Mason deal with modified files. If you tell Apache::Reload to look only at certain namespaces, this problem doesn't exist anymore. Am I still missing something ? Harry Danilevsky [EMAIL PROTECTED] Stas Bekman wrote: [...] Anyway, I decided to add another directive to Apache::Reload PerlSetVar ReloadDirectories /site/lib /usr/local/apache/conf Apache::Reload allows you to define which modules to reload using the patterns like so: PerlSetVar ReloadAll Off PerlSetVar ReloadModules Apache::* My::* Is there any reason why you cannot use this approach? I've no objection to your proposal, just wondering whether the existing features can be used instead. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Apache::Reload question...
I've got a "reality check" question for people to see that I'm not missing something obvious with our Apache::Reload mod_perl setup. We've recently install Apache::Reload at our site in production and it's working great. In what isprobably not the best 'software engineering' style, we've been known to upload several small patches in a single day and used to have to do short restarts to integrate the new code. We now use Apache::Reload instead. Rather than putting 'use Apache::Reload' in each of our modules, I've created a touch file, which after looking through the Apache::Reload code, I noted that you could put a list of modules into it which would be reloaded. On top of this, weuse mod_accelas a front end to our mod_perl backend.This combination seems to work great as well for anyone curious. The question I had regards where to put the 'Apache::Reload' directive. The documentation suggests something like: PerlInitHandler Apache::Reload PerlSetVar ReloadAll Off PerlSetVar ReloadTouchFile /tmp/reload_modules The problem I see in a production machine is that each child process will see this on the next request, and attempt to reload it's modules. At that point, you'll loose the shared memory the modules use between child processes. On top of this, the parent process will never get this, so it will never reload modules in the parent.The next time a new child is forked, on the first request it receives it will again attempt to reload the changed modules. Is this correct? Or am I missing something? The alternative I've used is this: PerlRestartHandler Apache::Reload PerlSetVar ReloadAll Off PerlSetVar ReloadTouchFile /tmp/reload_modules Then when I've uploaded any changes, I touch the change file, and do an 'apachectl graceful' to restart the backend. I think this works nicely because: 1)The mod_accel front end will buffer any long file uploads, and any long file downloads. So the actual length of connections from the frontend to the backend is only as long as it takes to process the request and tunnel the data betwen the front-back or back-front. Thus the 'graceful' restart only ever takes a few seconds, and no connections are ever lost, only blocked for a few seconds at the most (the length of the longest request to process). 2) Doing it in the restart handler means that the parent process reloads the modules, and all the newly forked children have shared copies. Can anyone tell me if I'm missing something here? Rob
Re: Apache::Reload question...
The question I had regards where to put the 'Apache::Reload' directive. The documentation suggests something like: PerlInitHandler Apache::Reload PerlSetVar ReloadAll Off PerlSetVar ReloadTouchFile /tmp/reload_modules The problem I see in a production machine is that each child process will see this on the next request, and attempt to reload it's modules. At that point, you'll loose the shared memory the modules use between child processes. that sounds right to me On top of this, the parent process will never get this, so it will never reload modules in the parent. The next time a new child is forked, on the first request it receives it will again attempt to reload the changed modules. Is this correct? Or am I missing something? I'm not sure about that. The alternative I've used is this: PerlRestartHandler Apache::Reload PerlSetVar ReloadAll Off PerlSetVar ReloadTouchFile /tmp/reload_modules Then when I've uploaded any changes, I touch the change file, and do an 'apachectl graceful' to restart the backend. I think this works nicely because: [snip] 2) Doing it in the restart handler means that the parent process reloads the modules, and all the newly forked children have shared copies. Can anyone tell me if I'm missing something here? that sounds right to me. I've not tested it with Apache::Reload specifically, but I did test using Apache::RegistryLoader with a PerlRestartHandler to reload Registry scripts in the parent process on restart and it seemed to work as we both suspected (recipe 17.4 bears the fruit of this labor :) I suspect that it is the same with Apache::Reload unless there is something specific to the reloading logic that prevents it. --Geoff
Apache::Reload
After much fluffing around I managed to get Apache::Reload to work for .pm
files with:
httpd.conf
Location /
PerlRequire /the/path/to/the/perl/startup.pl
PerlInitHandler Apache::Reload
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
/Location
/httpd.conf
BUT
Is it possible to get simple library files (ie. No package def.) to be
reloaded too?
For example:
index.cgi
#! /usr/bin/perl -w
use strict;
require test.pl;
go();
/index.cgi
test.pl
sub go
{
print Hello Worldbr;
}
1;
/test.pl
Changes to sub go in test.pl DO NOT get reloaded, but I'd like them to. Yes,
I could just make this a package but I'd rather not.
Luke Pascoe
Developer
IT Support Development Limited
http://www.itsd.co.nz
Mobile: (021) 303019
Email: [EMAIL PROTECTED]
How to reload PERL module in all Apache children
Hello,
I was wondering if there is a possibility to reload PERL module compiled
into Apache
with Apache::Registry
(and I want to reload this module in all Apache children processes) by
running reload-program once.
For example Apache::Reload must be set as PerlInitHandler, so it's handler
method is run every time request comes to Apache. What I'd like to do is to
reload specified (or all) module by running the program ONCE.
I tried using something like perl-status:
Location /mod-perl-reload
SetHandler perl-script
PerlHandler Apache::MyReloadModule
/Location
where MyReloadModule's handler was deleting specified module from %INC and
reloading it by require, but it didn't satisfy me becouse changes weren't
seen in apache children processess (at least I think so),
so I wrote something like this in MyReloadModule:
sub handler {
my $r = shift;
Apache-request($r);
.
.sending HTML
.
foreach my $k (keys %INC) {
$r-print($kBR);
}
$r-print(PID $$);
$r-print(/BODY/HTML);
}
and I realised that changes I have made to %INC in one child process aren't
seen in another one.
So my problem can be set in another way:
Do apache children communicate between themselves?
Is it possible to write such a reloader script as I wanted to write?
Maybe somebody already done this?
Thanks in advance,
Tomek Paterek
Re: How to reload PERL module in all Apache children
Waldek Grudzien wrote:
Hello,
I was wondering if there is a possibility to reload PERL module compiled
into Apache
with Apache::Registry
(and I want to reload this module in all Apache children processes) by
running reload-program once.
For example Apache::Reload must be set as PerlInitHandler, so it's handler
method is run every time request comes to Apache. What I'd like to do is to
reload specified (or all) module by running the program ONCE.
I tried using something like perl-status:
Location /mod-perl-reload
SetHandler perl-script
PerlHandler Apache::MyReloadModule
/Location
where MyReloadModule's handler was deleting specified module from %INC and
reloading it by require, but it didn't satisfy me becouse changes weren't
seen in apache children processess (at least I think so),
so I wrote something like this in MyReloadModule:
sub handler {
my $r = shift;
Apache-request($r);
.
.sending HTML
.
foreach my $k (keys %INC) {
$r-print($kBR);
}
$r-print(PID $$);
$r-print(/BODY/HTML);
}
and I realised that changes I have made to %INC in one child process aren't
seen in another one.
So my problem can be set in another way:
Do apache children communicate between themselves?
no
Is it possible to write such a reloader script as I wanted to write?
no
Maybe somebody already done this?
see above
The processes are forked and don't share the perl iterpreter, that's why
it's impossible to do what you are trying to do.
If you try to reload data it's doable by many ways (IPC, dbm, etc), not
the code.
Currently Apache::Reload or its equivalent your only solution. With
mod_perl 2.0 it'll be doable, if you run a single threaded server.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: How to reload PERL module in all Apache children
Hi Stas, I was wondering if there is a possibility to reload PERL module compiled into Apache with Apache::Registry (and I want to reload this module in all Apache children processes) by running reload-program once. Currently Apache::Reload or its equivalent your only solution. With mod_perl 2.0 it'll be doable, if you run a single threaded server. So you mean any modules changed can be reloaded to all children, without actually terminating and starting the server ? (or does single threaded means there are no children ?) Sreeji __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Re: How to reload PERL module in all Apache children
Sreeji K Das wrote: Hi Stas, I was wondering if there is a possibility to reload PERL module compiled into Apache with Apache::Registry (and I want to reload this module in all Apache children processes) by running reload-program once. Currently Apache::Reload or its equivalent your only solution. With mod_perl 2.0 it'll be doable, if you run a single threaded server. So you mean any modules changed can be reloaded to all children, without actually terminating and starting the server ? (or does single threaded means there are no children ?) Sorry, I should have said within a single process with multiple threads. I just said it'll be doable because of threads, (which all share the same process memory). I'm not sure if this already works this way. Give it a try, Apache::Reload is a now in the 2.0 core. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [Fwd: Re: How to reload PERL module in all Apache children]
if you use Apache::Reload with a threaded MPM and multiple interpreters, the modules will be reloaded by each interpreter as they are used, not every interpreter all at once. similar to 1.x where each child has its own interpreter, the modules are reloaded as each kid is hit with a request. note that if a module is loaded at startup, the syntax tree of each subroutine is shared between interpreters (big win), but each subroutine has its own padlist (where lexical my variables are stored). once Apache::Reload reloads a module, this sharing goes away and each interpreter will have its own copy of the syntax tree for the given subroutines.
Re: [Fwd: Re: How to reload PERL module in all Apache children]
[EMAIL PROTECTED] wrote: if you use Apache::Reload with a threaded MPM and multiple interpreters, the modules will be reloaded by each interpreter as they are used, not every interpreter all at once. similar to 1.x where each child has its own interpreter, the modules are reloaded as each kid is hit with a request. thanks for correcting me. It's all about interpreters and not threads, so it's the same for the code with forked and threaded httpds. But if talk about futuristic Solar variables (perl globals shared between threads). what if a solar variable is a reference to CODE? Can this be shared? If so, will reloading this variable in one interpreter affect others? Also if we put the sharing aside for a moment and assuming that we have a pool of interpreters with idle interpreters in it, there can be a thread that monitors changed modules and update the idle interpreters by making them reload the code and put them in the head of the list. This should save the overhead of reloading during a request. Does this make sense? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [Fwd: Re: How to reload PERL module in all Apache children]
On Fri, 12 Apr 2002, Stas Bekman wrote: But if talk about futuristic Solar variables (perl globals shared between threads). what if a solar variable is a reference to CODE? Can this be shared? If so, will reloading this variable in one interpreter affect others? even if that would work, it would kill performance due to required mutex locking. and that locking would need to happen in the perl core, unlike simple scalars, arrays and hashes. Also if we put the sharing aside for a moment and assuming that we have a pool of interpreters with idle interpreters in it, there can be a thread that monitors changed modules and update the idle interpreters by making them reload the code and put them in the head of the list. This should save the overhead of reloading during a request. Does this make sense? there already is a plan to have a low-priority thread that monitors idle interpreters. this would be a pluggable interface, so you can do whatever you want with the interpreter via callback hooks. but that'll all wait until well after everything else is solid with ithreads, including and most important: perl 5.8.x
Re: [Fwd: Re: How to reload PERL module in all Apache children]
[EMAIL PROTECTED] wrote: On Fri, 12 Apr 2002, Stas Bekman wrote: But if talk about futuristic Solar variables (perl globals shared between threads). what if a solar variable is a reference to CODE? Can this be shared? If so, will reloading this variable in one interpreter affect others? even if that would work, it would kill performance due to required mutex locking. and that locking would need to happen in the perl core, unlike simple scalars, arrays and hashes. Does it look you'll be able to get the solar variables idea to work for those data types? - Perrin
Re: [Fwd: Re: How to reload PERL module in all Apache children]
On Thu, 11 Apr 2002, Perrin Harkins wrote: Does it look you'll be able to get the solar variables idea to work for those data types? i had a simple prototype way back that sorta worked for simple scalars, probably won't take it any further now that there is threads::shared in 5.7.x. haven't tried it but i believe the concept is the same.
How to reload module in all Apache children.
Hi folks,
I was wondering if there is a possibility to reload perl
module(and I want reloaded module in all Apache children processes) by
runningreload-program once.
For example Apache::Reload must be set as PerlInitHandler, so
it's handler method is run every time request comes to Apache. What I'd like to
do is to reload specified (or all) module by runningthe program
ONCE.
I tried using something like perl-status:
Location
/mod-perl-reloadSetHandler perl-scriptPerlHandler
Apache::MyReloadModule/Location
where MyReloadModule's handler was deleting
specified module from %INC and reloading itby require, but it didn't
satisfy me becouse changes weren't seen in apache children processess (at least
I think so),
so I wrote something like this in
MyReloadModule:
sub handler {
my $r =
shift; Apache-request($r);
.
. sending
HTML
.
foreach my $k (keys %INC)
{
$r-print("$kBR"); }
$r-print("PID $$");
$r-print("/BODY/HTML");
}
and I realised that
changes I have made to %INC in one child process aren't seen in another
one.
So
my problem can be set in another way:
Doapache children communicate between
themselves?
Is it possible to write such a script as I wanted to
write?
Maybe somebody already done this?
Thanks in advance,
Tomek Paterek
Apache::Reload question
Can Apache::Reload be used to reload modules that are use-d by httpd PerlModule, PerlRequire, or PerlHandler directives, or do they have to be explicitly use-d in code that is inside a handler? I think the answer is yes - these are no different than anything else except that memory sharing is lost because reload occurs in the children but wanted to check before I go down that path. Matthew Pressly
Re: Apache::Reload
James wrote: Thus spake Christoph Lange ([EMAIL PROTECTED]): I am using use Apache::Reload; in a module but it does not work. I tell my main-script where to find this module via use lib '/home/path/for/modules'. Might this be the (or one) reason why Apache::Reload does not work? Do I have to add the path for my modules to @INC in the server-startup file. And if, how? Yes. Something like the following works well. perl use lib qw( /path/to/my/libs ); /perl PerlInitHandler Apache::Reload just to explain why this happens: you didn't tell that you run under some registry handler, but apparently you are. registry handlers reset @INC after script's compilation, so if you want to *change* @INC, you should do it at the server startup, as James has answered to you. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Apache::Reload
Hi, I am using "use Apache::Reload;" in a module but it does not work. I tell my "main"-script where to find this module via "use lib '/home/path/for/modules'". Might this be the (or one) reason why Apache::Reload does not work? Do I have to add the path for my modules to @INC in the server-startup file. And if, how? Thanks for your help, Chris
Re: Apache::Reload
Thus spake Christoph Lange ([EMAIL PROTECTED]): I am using use Apache::Reload; in a module but it does not work. I tell my main-script where to find this module via use lib '/home/path/for/modules'. Might this be the (or one) reason why Apache::Reload does not work? Do I have to add the path for my modules to @INC in the server-startup file. And if, how? Yes. Something like the following works well. perl use lib qw( /path/to/my/libs ); /perl PerlInitHandler Apache::Reload -- James [EMAIL PROTECTED] 1024D/62C2F77D uri: http://oneiros.darkspire.net/ EBB8 AF14 8C43 2F12 7623 irc: EFnet / opn / tietnet C0AA C0AE 56D4 62C2 F77D
Re: Apache::Reload : eval { require $filename }
On Thu, 2 Aug 2001, Sidharth Malhotra wrote: In the Apache::Reload module, if the 'require' fails, your script bails out, and your client gets status 500. The side effect is that totally unrelated scripts can fail because a bad programmer on another end of the system forgot my a variable. My proposed solution is to put the require inside an eval. Upon failure, simply write to the error log. My Question: If the require is in an eval, what happens when a reload fails? Does the old code in memory stay or or is it removed w/out being replaced by the updated code? Apache::Reload shouldn't be used on production systems. At least in the way you describe. This dissolves the problem. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Apache::Reload : eval { require $filename }
On Thu, 2 Aug 2001, Sidharth Malhotra wrote: SM In the Apache::Reload module, if the 'require' fails, your script SM bails out, and your client gets status 500. The side effect is SM that totally unrelated scripts can fail because a bad programmer SM on another end of the system forgot my a variable. SM SM My proposed solution is to put the require inside an eval. Upon SM failure, simply write to the error log. I already handle this in my own code in a system with pluggable user modules. I want to control myself if the scripts dies (which is does on system modules) or not (which it does not on user supplied modules). SM My Question: If the require is in an eval, what happens when a reload SM fails? Does the old code in memory stay or or is it removed w/out being SM replaced by the updated code? I do not want Apache::Reload to remove this control from me, and I do not under any case want old code to remain in memory or be removed, and execution continue, when I have given a reload command. That would be a major security risk. -- Henrik Edlund [EMAIL PROTECTED] http://www.edlund.org/ You're young, you're drunk, you're in bed, you have knives; shit happens. -- Angelina Jolie
RE: Apache::Reload???
Does that work under Unix only? I am on NT and it does not appear to work. Can someone clarify. Thanks Scott -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 31, 2001 9:38 PM To: Bryan Coon Cc: Matt Sergeant; '[EMAIL PROTECTED]' Subject: Re: Apache::Reload??? On Tue, 31 Jul 2001, Bryan Coon wrote: I must have missed something in setting up Apache::Reload. What I want is simple that when I make a change in my scripts I dont have to restart the Apache server... I put PerlInitHandler Apache::Reload in my httpd.conf, and added 'use Apache::Reload' to the modules that I want to be reloaded on change. But I get the following warning message in my apache logs: Apache::Reload: Can't locate MyModule.pm for every module I have added Apache::Reload to. How do I do this so it works? The docs on Reload are a bit sparse... Your problem probably comes from the fact that @INC is reset to its original value after its get temporary modified in your scripts. Of course when Apache::Reload tries to find the file to test for its mod time, it cannot find it. The solution is to extend @INC at the server startup to include directories you load the files from which aren't in @INC. For example, if you have a script which loads MyTest.pm from /home/stas/myproject: use lib qw(/home/stas/myproject); require MyTest; Apache::Reload won't find this file, unless you alter @INC in startup.pl: startup.pl -- use lib qw(/home/stas/myproject); and restart the server I'll add these notes to the guide. Matt probably wants to add these to the Apache::Reload docs as well :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: Apache::Reload???
That worked :) Ahh, at least I solved ONE problem! Thanks! Bryan The solution is to extend @INC at the server startup to include directories you load the files from which aren't in @INC. For example, if you have a script which loads MyTest.pm from /home/stas/myproject: use lib qw(/home/stas/myproject); require MyTest; Apache::Reload won't find this file, unless you alter @INC in startup.pl: startup.pl -- use lib qw(/home/stas/myproject); and restart the server
One more small Apache::Reload question
First, thanks to all the great suggestions, it looks like it works fine. However, now my logs are loaded with a ton of subroutine redefined warnings (which is normal I suppose?). I can certainly live with this in a development environment, but thought I would check to see if it is expected, and if it can be turned off while still enabling Reload. Thanks! Bryan
RE: One more small Apache::Reload question
Those warnings are normal, and you can use the warnings pragma to turn them off. (Although, I believe the warnings pragma only exists in Perl 5.6.0+). use warnings; no warnings qw(redefine); - Kyle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bryan Coon Sent: Wednesday, August 01, 2001 9:36 AM To: '[EMAIL PROTECTED]' Subject: One more small Apache::Reload question First, thanks to all the great suggestions, it looks like it works fine. However, now my logs are loaded with a ton of subroutine redefined warnings (which is normal I suppose?). I can certainly live with this in a development environment, but thought I would check to see if it is expected, and if it can be turned off while still enabling Reload. Thanks! Bryan
RE: One more small Apache::Reload question
However, now my logs are loaded with a ton of subroutine redefined warnings (which is normal I suppose?). I can certainly live with this in a development environment, but thought I would check to see if it is expected, and if it can be turned off while still enabling Reload. Well, first of all, you will want to turn off Apache::Reload during production. All of those stat()'s will slow down your server speed significantly, as the disk is kept busy for each request. Secondly, how is it you view your logs? I have a window running tail -f with a grep filter: tail -f /var/log/httpd/error_log | egrep -v 'redefined.at|Apache::Reload|AuthenCache' This way, I get the best of both worlds, by ignoring the noise: # use constant SIGNATURE = 'TSTAT'; Constant subroutine SIGNATURE redefined at /usr/lib/perl5/5.00503/constant.pm line 175. # One of my module's subroutines.. there are 15 of these Subroutine test_handler redefined at /etc/httpd/lib/perl/Stat/Count.pm line 315 I have AuthenCache in my filter because at LogLevel debug, Apache::AuthenCache is *noisy*!! HTH! L8r, Rob #!/usr/bin/perl -w use Disclaimer qw/:standard/;
Apache::Reload???
I must have missed something in setting up Apache::Reload. What I want is simple that when I make a change in my scripts I dont have to restart the Apache server... I put PerlInitHandler Apache::Reload in my httpd.conf, and added 'use Apache::Reload' to the modules that I want to be reloaded on change. But I get the following warning message in my apache logs: Apache::Reload: Can't locate MyModule.pm for every module I have added Apache::Reload to. How do I do this so it works? The docs on Reload are a bit sparse... Thanks! Bryan
RE: Apache::Reload???
Apache::Reload works by performing a stat on every file in %INC and calling require for all the files that changed. It's quite possible that some of the files in %INC are using relative paths (often '.' is in @INC). So, Perl was able to load the file originally because the initial 'use' or 'require' was after Apache changed to your directory. However, when Apache::Reload goes to look for the file, it can't find it because the current directory is different (most likely the ServerRoot). You can fix the problem by installing your modules in a directory that is fully qualified in @INC. - Kyle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bryan Coon Sent: Tuesday, July 31, 2001 3:16 PM To: '[EMAIL PROTECTED]' Subject: Apache::Reload??? I must have missed something in setting up Apache::Reload. What I want is simple that when I make a change in my scripts I dont have to restart the Apache server... I put PerlInitHandler Apache::Reload in my httpd.conf, and added 'use Apache::Reload' to the modules that I want to be reloaded on change. But I get the following warning message in my apache logs: Apache::Reload: Can't locate MyModule.pm for every module I have added Apache::Reload to. How do I do this so it works? The docs on Reload are a bit sparse... Thanks! Bryan
Why can't Apache::Reload work 100% transparently?
On Tue, 31 Jul 2001, Kyle Oppenheim wrote: Apache::Reload works by performing a stat on every file in %INC and calling require for all the files that changed. It's quite possible that some of the files in %INC are using relative paths (often '.' is in @INC). So, Perl was able to load the file originally because the initial 'use' or 'require' was after Apache changed to your directory. However, when Apache::Reload goes to look for the file, it can't find it because the current directory is different (most likely the ServerRoot). I've ran into this problem with Apache::Reload a couple of times myself. Isn't there a way that Apache::Reload can be made to work transparently (in the spirit of making programs Do The Right Thing (tm))? Perhaps by overloading the use and require functions to convert pathnames to be fully qualified before inserting them in %INC? (I think this would also help with same-named mod_perl scripts from different VirtualHosts in the same instance of Apache interfering with each others' execution?)
RE: Apache::Reload???
-Original Message-
From: Kyle Oppenheim
To: [EMAIL PROTECTED]
Sent: 7/31/01 10:01 PM
Subject: RE: Apache::Reload???
Apache::Reload works by performing a stat on every file in %INC and
calling
require for all the files that changed. It's quite possible that some
of
the files in %INC are using relative paths (often '.' is in @INC). So,
Perl
was able to load the file originally because the initial 'use' or
'require'
was after Apache changed to your directory. However, when
Apache::Reload
goes to look for the file, it can't find it because the current
directory is
different (most likely the ServerRoot).
actually, I don't think that is true in the latest version of Apache::Reload
for (@INC) {
$mtime = (stat $_/$file)[9];
last if defined($mtime) $mtime;
}
which should work with any packages that are real files and not package
declarations within other packages I would think.
Apache::Reload: Can't locate MyModule.pm for every module I have added
Apache::Reload to.
I actually got bitten by this just today when I realized that root directory
that starts my @INC was set to 700. perhaps there is a permissions problem
in there - don't forget that Apache runs as nobody so nobody has to actually
be able to stat() the file (just to point out the obvious ;)
HTH
--Geoff
Re: Apache::Reload???
On Tue, 31 Jul 2001, Bryan Coon wrote: I must have missed something in setting up Apache::Reload. What I want is simple that when I make a change in my scripts I dont have to restart the Apache server... I put PerlInitHandler Apache::Reload in my httpd.conf, and added 'use Apache::Reload' to the modules that I want to be reloaded on change. But I get the following warning message in my apache logs: Apache::Reload: Can't locate MyModule.pm for every module I have added Apache::Reload to. How do I do this so it works? The docs on Reload are a bit sparse... Your problem probably comes from the fact that @INC is reset to its original value after its get temporary modified in your scripts. Of course when Apache::Reload tries to find the file to test for its mod time, it cannot find it. The solution is to extend @INC at the server startup to include directories you load the files from which aren't in @INC. For example, if you have a script which loads MyTest.pm from /home/stas/myproject: use lib qw(/home/stas/myproject); require MyTest; Apache::Reload won't find this file, unless you alter @INC in startup.pl: startup.pl -- use lib qw(/home/stas/myproject); and restart the server I'll add these notes to the guide. Matt probably wants to add these to the Apache::Reload docs as well :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Why can't Apache::Reload work 100% transparently?
On Tue, 31 Jul 2001, Philip Mak wrote: On Tue, 31 Jul 2001, Kyle Oppenheim wrote: Apache::Reload works by performing a stat on every file in %INC and calling require for all the files that changed. It's quite possible that some of the files in %INC are using relative paths (often '.' is in @INC). So, Perl was able to load the file originally because the initial 'use' or 'require' was after Apache changed to your directory. However, when Apache::Reload goes to look for the file, it can't find it because the current directory is different (most likely the ServerRoot). I've ran into this problem with Apache::Reload a couple of times myself. Isn't there a way that Apache::Reload can be made to work transparently (in the spirit of making programs Do The Right Thing (tm))? Perhaps by overloading the use and require functions to convert pathnames to be fully qualified before inserting them in %INC? This is a good idea, though you cannot do that unless you are running under 5.6 or some earlier Perl which supports the notion of GLOBAL::CORE:: namespace (which can be a bad thing to do anyway). Or write some XS code :) Extending your @INC is the simplest solution. The docs should be updated and you will be all set. (I think this would also help with same-named mod_perl scripts from different VirtualHosts in the same instance of Apache interfering with each others' execution?) Not really. You have 1:1 mapping in %INC. How exactly do you suggest it to work? It'll be all clean in mod_perl 2.0, where every vh will have its own pool of interpreters if wanted, with a private copy of %INC. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Using Apache::Reload in development environment?
On Sun, 29 Jul 2001, Philip Mak wrote: I have a site running mod_perl that I'm constantly making changes to. What do I have to do in order to make it so that when I edit any file (either a .pl script directly called on the site, or a .pm module that my perl script uses), then the changes will take effect automatically? I would rather not have to go into each file manually and put use Apache::Reload. Do I just put PerlInitHandler Apache::Reload in httpd.conf? Is there anything else that I have to do? no (re-)?read the manpage. it's all there. It's possible that Matt wants to add other options to the SYNOPSIS section, as not everybody bothers to read the manpage. I think people are used to see all of the functionality covered in SYNOPSIS. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Using Apache::Reload in development environment?
On Mon, 30 Jul 2001, Stas Bekman wrote: no (re-)?read the manpage. it's all there. It's possible that Matt wants to add other options to the SYNOPSIS section, as not everybody bothers to read the manpage. I think people are used to see all of the functionality covered in SYNOPSIS. In perldoc Apache::Reload, the DESCRIPTION has the following sections: - StatINC Replacement - Register Modules Implicitly - Register Modules Explicitly - Special Touch File I just re-read it again and realized that StatINC Replacement is what I wanted... although it wasn't obvious from just reading the header since I don't know what StatINC is. Re-reading the first paragraph of DESCRIPTION, I see that it implies that StatINC always checks the modification time of the file. I was also somewhat confused as to what PerlSetVar ReloadAll does since that perldoc page did not have an explicit definition, only examples of it being used.
Re: Using Apache::Reload in development environment?
--On 30/07/01 06:43 -0400 Philip Mak wrote: In perldoc Apache::Reload, the DESCRIPTION has the following sections: - StatINC Replacement - Register Modules Implicitly - Register Modules Explicitly - Special Touch File I just re-read it again and realized that StatINC Replacement is what I wanted... although it wasn't obvious from just reading the header since I don't know what StatINC is. Re-reading the first paragraph of DESCRIPTION, I see that it implies that StatINC always checks the modification time of the file. I was also somewhat confused as to what PerlSetVar ReloadAll does since that perldoc page did not have an explicit definition, only examples of it being used. PerlSetVar ReloadAll will reload all modules. That might take some time, so you might want to reload only your own modules, in which case you set it to Off, and add a directive to reload only your tree, such as PerlSetVar ReloadModules Foo::* Bar::* -- Eric Cholet 145C FF7F 7920 04B0 7BA3 48D8 5591 E2C0 6664 C078
Using Apache::Reload in development environment?
I have a site running mod_perl that I'm constantly making changes to. What do I have to do in order to make it so that when I edit any file (either a .pl script directly called on the site, or a .pm module that my perl script uses), then the changes will take effect automatically? I would rather not have to go into each file manually and put use Apache::Reload. Do I just put PerlInitHandler Apache::Reload in httpd.conf? Is there anything else that I have to do?
StatINC Reload on NT
I have begun development on a new project and I am using Apache on NT with mod_perl. I have created a lot of modules and I am using them in my code. The problem is that as I continue to develop, some modules keep changing, and I am getting tired of restarting the server. I have read the mod_perl Coding guidelines three times now. Under the coding guidelines it has the example of using Apache::StatINC. I followed it the instructions exactly, but yet, it does NOT work. After that I tried Apache::Reload both ways with no success. Has anyone out there got either of these working on NT? I do not want to use work-arounds on this large project. I really need to have the ability to reload these modules on each hit to the server while developing the core code set. I even have the apache book, but I can't find any mention of this there either. Please advise. Scott Purcell
Reload Modules on NT Apache
Hello, I am using mod-perl, and I am in the development stages of coding. Each time I make a code change to a module, I must restart apache. I know there must be docs for this, but I cannot find them from the apache web site. Could someone assist me in finding those? Or if someone knows of a simple way to accomplish this task, please advise. Thanks Scott Purcell
Re: Reload Modules on NT Apache
I am using mod-perl, and I am in the development stages of coding. Each time I make a code change to a module, I must restart apache. I know there must be docs for this, but I cannot find them from the apache web site. Could someone assist me in finding those? Or if someone knows of a simple way to accomplish this task, please advise. Scott, There is a module called StatINC which is supposed to solve this problem. I've had trouble with it but it is probably something I am doing wrong as I never fully investigated. Alternatively, depending what you are doing, you might be able to add the packages to the script which would otherwise use them during development so that they get recompiled every time. This wouldn't work very well if you are sharing the modules between a bunch of programs, obviously, but if you are trying to debug something it might help. Tim
Sending Cookies on Page-Reload
Hi,
i am using a Cookie which has a timeout as a -value,
when it expires i want to send a new one which should replace this one.
it the accesshandler is have a
verify_cookie-method which
checks the timeout, if it's expired then i call
...
$cookie = CGI::Cookie-new(-name = 'myCookie',... etc -Value = {'Time' = $newtime
})
$r-headers_out-add($cookie);
...
If the user is surfing to different pages this works,
but if he just hits reload the cookie is not being set by the browser
(Netscape seems to check the date of the file or something like that)
OR the browser gets the old cookie again - at least thats what Konqueror tells me.
Is there a way to force a browser to set a new cookie on reload?
Thanks,
Nenad
