perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Swartz <swa...@pobox.com>
Subject Re: a better way to recognize module changes
Date Fri, 11 Sep 2009 22:57:00 GMT

On Sep 11, 2009, at 3:53 PM, Fred Moyer wrote:

> On Fri, Sep 11, 2009 at 3:37 PM, Jonathan Swartz <swartz@pobox.com>  
> wrote:
>>
>>> On Fri, Sep 11, 2009 at 3:11 PM, Jonathan Swartz  
>>> <swartz@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 properly. Sometimes the  
>>>>>> failure
>>>>>> is intermittent, depending on the order of module loading and  
>>>>>> other
>>>>>> esoteric details. Moose and ORM modules seem particularly prone 

>>>>>> to
>>>>>> reload failures. For me, this level of unpredictability makes
>>>>>> *::Reload too frustrating to use.
>>>
>>> I've run into issues with reloading ORM based modules such as when I
>>> change my DBIx::Class based schema.  I get an inconsistent hierarchy
>>> error from Class::C3.  So in those cases a server restart is  
>>> required.
>>>
>>> However, if your model layer is abstracted from mod_perl, you should
>>> be able to develop against your model layer using tests, and then
>>> install your upgraded model and restart Apache then.  The behavior
>>> where I encounter problems reloading changes to ORM modules has
>>> enforced a good separation of model (ORM) and controller( mod_perl )
>>> code in my application.
>>
>> I'm all for TDD, to be sure, but in practice not everything -  
>> especially
>> with controller and view-specific modules - is going to be  
>> developed in this
>> way.
>>
>> I've often exhorted Mason developers to move things out of  
>> components into
>> modules, but a real objection to that has been the server restart  
>> cost, and
>> I've never had a good answer for it. Mason components (like TT  
>> templates,
>> etc.) can pretty much always be reloaded without restart, which I  
>> expect is
>> one reason why so much code ends up there.
>
> That makes a lot of sense.
>
> Only thing I could suggest would be to exclude your Moose based
> modules from Apache::Reload reload list if they are causing problems.
>
> Although, if there was a way to kill off user owned httpd processes
> when a code change was made, you could extend Apache::Reload to have
> certain modules cause httpd recycling vs code reloading.
>
> Maybe something like:
>
> 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 process itself,  
how can it implement ReloadHttpds effectively? It would have to kill  
itself off, which would mean your first request would generate an  
error - not a good user experience.


Mime
View raw message