On Fri, Sep 11, 2009 at 3:20 PM, Devin Teske <dte...@vicor.com> wrote: > 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?)
It was not included because of a miscommunication when releasing 0.10. You can install 0.10 from CPAN and should be fine. The conclusions after the post mortem were that the latest stable versions of Apache::* modules should be included with mod_perl core releases, but later versions of those modules should be easily upgradeable from CPAN. > -- > 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 <- > >
