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 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.te...@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 <- >> > >
