Was there any particular reason that it wasn't packaged with 2.0.4? (meaning, can I just supplant the one from 2.0.3... or was it removed only to be re-added after being patched for some particular purpose?) -- Devin
On Fri, 2009-09-11 at 15:11 -0700, Fred Moyer wrote: > 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 <- > > > > -- 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 <-
