Re: distributing software built on mod_perl

2009-09-11 Thread William T
Whenever I creating shrink-wrapped software I always make packaging and distribution part of the development, qa and testing process. All packages for the platforms that we will be supporting. The reason I do this is to cut down on the customer support overhead. I've found you get less calls

a better way to recognize module changes

2009-09-11 Thread Jonathan Swartz
I'm thinking about an improved solution to recognizing module changes in a running server, without restarting the server. These are the solutions I know about: 1) Apache2::Reload / Module::Reload These check whether modules have changed on each request, and if so, clear their symbols and

Re: a better way to recognize module changes

2009-09-11 Thread Perrin Harkins
On Fri, Sep 11, 2009 at 5:26 PM, Jonathan Swartz swa...@pobox.com wrote: This is the nicest solution I've seen so far. The only problem I can see is its performance - each potentially-changing module has to be loaded on each request. ** How long does it take for you? I've run a lot of large

Re: a better way to recognize module changes

2009-09-11 Thread Devin Teske
Maybe somebody can refute what I'm seeing, but as of mod_perl-2.0.4, Apache2::Reload is gone (so you can remove that from your list of options). -- Devin On Fri, 2009-09-11 at 14:26 -0700, Jonathan Swartz wrote: I'm thinking about an improved solution to recognizing module changes in a

Re: a better way to recognize module changes

2009-09-11 Thread Fred Moyer
On Fri, Sep 11, 2009 at 3:02 PM, Devin Teske dte...@vicor.com wrote: Maybe somebody can refute what I'm seeing, but as of mod_perl-2.0.4, Apache2::Reload is gone (so you can remove that from your list of options). It was not bundled with 2.0.4 but is available on CPAN:

Re: a better way to recognize module changes

2009-09-11 Thread Jonathan Swartz
It seems like it's available separately in Apache-Reload distribution: http://cpan.uwinnipeg.ca/dist/Apache-Reload But it's already pretty much a straw-man option for me. :) Jon On Sep 11, 2009, at 3:02 PM, Devin Teske wrote: Maybe somebody can refute what I'm seeing, but as of

Re: a better way to recognize module changes

2009-09-11 Thread Jonathan Swartz
On Sep 11, 2009, at 2:52 PM, Perrin Harkins wrote: On Fri, Sep 11, 2009 at 5:26 PM, Jonathan Swartz swa...@pobox.com wrote: This is the nicest solution I've seen so far. The only problem I can see is its performance - each potentially-changing module has to be loaded on each request. **

Re: a better way to recognize module changes

2009-09-11 Thread Devin Teske
Was there any particular reason that it wasn't packaged with 2.0.4? (meaning, can I just supplant the one from 2.0.3... or was it removed only to be re-added after being patched for some particular purpose?) -- Devin On Fri, 2009-09-11 at 15:11 -0700, Fred Moyer wrote: On Fri, Sep 11, 2009 at

Re: a better way to recognize module changes

2009-09-11 Thread Jonathan Swartz
Incidentally Perrin - how do you come up with the list of vendor (i.e. not your project's) modules to load in the parent? Do you just load a page, look at %INC, and then subtract out your personal modules? Do you have to do this every so often to catch new vendor modules that have snuck in

Re: a better way to recognize module changes

2009-09-11 Thread Fred Moyer
On Fri, Sep 11, 2009 at 3:20 PM, Devin Teske dte...@vicor.com wrote: Was there any particular reason that it wasn't packaged with 2.0.4? (meaning, can I just supplant the one from 2.0.3... or was it removed only to be re-added after being patched for some particular purpose?) It was not

Re: a better way to recognize module changes

2009-09-11 Thread Fred Moyer
On Fri, Sep 11, 2009 at 3:11 PM, Jonathan Swartz swa...@pobox.com wrote: It seems like it's available separately in Apache-Reload distribution: http://cpan.uwinnipeg.ca/dist/Apache-Reload But it's already pretty much a straw-man option for me. :) Problem: some modules fail to reload

Re: a better way to recognize module changes

2009-09-11 Thread Jonathan Swartz
On Fri, Sep 11, 2009 at 3:11 PM, Jonathan Swartz swa...@pobox.com wrote: It seems like it's available separately in Apache-Reload distribution: http://cpan.uwinnipeg.ca/dist/Apache-Reload But it's already pretty much a straw-man option for me. :) Problem: some modules fail to reload

Re: a better way to recognize module changes

2009-09-11 Thread Fred Moyer
On Fri, Sep 11, 2009 at 3:37 PM, Jonathan Swartz swa...@pobox.com wrote: On Fri, Sep 11, 2009 at 3:11 PM, Jonathan Swartz swa...@pobox.com wrote: It seems like it's available separately in Apache-Reload distribution: http://cpan.uwinnipeg.ca/dist/Apache-Reload But it's already pretty much a

Re: a better way to recognize module changes

2009-09-11 Thread Jonathan Swartz
On Sep 11, 2009, at 3:53 PM, Fred Moyer wrote: On Fri, Sep 11, 2009 at 3:37 PM, Jonathan Swartz swa...@pobox.com wrote: On Fri, Sep 11, 2009 at 3:11 PM, Jonathan Swartz swa...@pobox.com wrote: It seems like it's available separately in Apache-Reload distribution:

Re: a better way to recognize module changes

2009-09-11 Thread John Siracusa
On 9/11/09 6:57 PM, Jonathan Swartz wrote: PerlSetVar ReloadAll On PerlSetVar ReloadHttpds My::Moose So that modules in ReloadHttpds terminates existing user httpd processes and causes the server to fork off new httpd children. But again, if Apache::Reload runs as part of the child

FW: Apache::DBI Failed due to +GlobalRequest

2009-09-11 Thread Kulasekaran, Raja
Hi, I have configured with my apache 2.2 with Mod perl. When I tried to use Apache::DBI for persistent Database connection, It shows the below error [Thu Sep 10 14:39:30 2009] [error] Global $r object is not available. Set:\n\tPerlOptions +GlobalRequest\nin httpd.conf at