perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Moyer <f...@redhotpenguin.com>
Subject Re: a better way to recognize module changes
Date Fri, 11 Sep 2009 22:53:23 GMT
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.

>
> Jon
>
>

Mime
View raw message