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:26:19 GMT
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.


>

> Jon
>
> On Sep 11, 2009, at 3:02 PM, Devin Teske 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).
>> --
>> 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 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 reload them inside the process.
>>>
>>> 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.
>>>
>>> 2) Catalyst auto-restart
>>>
>>> Catalyst has an engine (Catalyst::Engine::HTTP::Prefork::Restarter)
>>> which forks off a "watcher" process that waits for your modules to
>>> change. When they change, it restarts the server. The usual effect is
>>> that, between the time you hit "save" in your editor and reload your
>>> page, the server has restarted or at least begun restarting.
>>>
>>> Problems: Doesn't work well if you make a few changes in a row; the
>>> restart only captures your first change. Bad user experience if
>>> there's an error in your module; you have to realize the server has
>>> died, find the error message in some shell or log, and manually start
>>> up the server again.
>>>
>>> 3) Perrin's MaxRequestsPerChild=1
>>>
>>> Perrin recently alerted me to the MaxRequestsPerChild=1 technique.
>>> That is, set MaxRequestsPerChild to 1, then load any potentially-
>>> changing modules in the *child*, not the parent (obviously only for
>>> development environments). Each request will hit a fresh child server,
>>> which will load all of your potentially-changing modules anew.
>>>
>>> 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. **
>>>
>>> 4) My idea: Combine 2 and 3
>>>
>>> As in 3, load any potentially-changing modules in the child. Leave
>>> MaxRequestsPerChild alone. As in 2, fork off a "watcher" process that
>>> waits for your modules to change. When they change, kill all the
>>> server's children explicitly.
>>>
>>> The end result is that you get reasonable performance when your
>>> modules don't change (e.g. when you are only futzing with templates),
>>> but when modules do change, you should see the effects immediately.
>>>
>>> This should be able to work with mod_perl, fastcgi, Net::Server, etc.,
>>> as long as the parent server responds appropriately to the killing of
>>> all its children (by launching new ones). Apache, at least, seems to
>>> be ok with this.
>>>
>>> What do people think? Is this worth codifying in a module, or does
>>> something like this already exist?
>>>
>>> Thanks for any feedback
>>> Jon
>>>
>>>
>>> ** - You can try to load things only on demand, but often mod_perl
>>> code is written without 'use' statements as it assumes everything is
>>> loaded in the parent. You can also try to minimize the number of
>>> potentially-changing modules, but then you run the risk of leaving
>>> something off and having to adjust it and restart.
>>>
>> --
>> Cheers,
>> Devin Teske
>>
>> -> CONTACT INFORMATION <-
>> Field Engineer
>> Metavante Corporation
>> 626-573-6040 Office
>> 510-735-5650 Mobile
>> devin.teske@metavante.com
>>
>> -> LEGAL DISCLAIMER <-
>> This message  contains confidential  and proprietary  information
>> of the sender,  and is intended only for the person(s) to whom it
>> is addressed. Any use, distribution, copying or disclosure by any
>> other person  is strictly prohibited.  If you have  received this
>> message in error,  please notify  the e-mail sender  immediately,
>> and delete the original message without making a copy.
>>
>> -> END TRANSMISSION <-
>>
>
>

Mime
View raw message