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:11:34 GMT
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 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