On Fri, Sep 11, 2009 at 3:02 PM, Devin Teske <dte...@vicor.com> 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).
It was not bundled with 2.0.4 but is available on CPAN: http://search.cpan.org/dist/Apache-Reload It will be bundled again with 2.0.5. There was a discussion on the dev list about how to manage perl based Apache2?::* modules with mod_perl core releases and the specific version control procedures to accomplish this in a pain free manner. > -- > 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 <- > >
