On Sep 11, 2009, at 3:53 PM, Fred Moyer wrote:
On Fri, Sep 11, 2009 at 3:37 PM, Jonathan Swartz <[email protected]>
wrote:
On Fri, Sep 11, 2009 at 3:11 PM, Jonathan Swartz
<[email protected]> 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.
I'm all for TDD, to be sure, but in practice not everything -
especially
with controller and view-specific modules - is going to be
developed in this
way.
I've often exhorted Mason developers to move things out of
components into
modules, but a real objection to that has been the server restart
cost, and
I've never had a good answer for it. Mason components (like TT
templates,
etc.) can pretty much always be reloaded without restart, which I
expect is
one reason why so much code ends up there.
That makes a lot of sense.
Only thing I could suggest would be to exclude your Moose based
modules from Apache::Reload reload list if they are causing problems.
Although, if there was a way to kill off user owned httpd processes
when a code change was made, you could extend Apache::Reload to have
certain modules cause httpd recycling vs code reloading.
Maybe something like:
PerlSetVar ReloadAll On
PerlSetVar ReloadHttpds My::Moose
So that modules in ReloadHttpds terminates existing user httpd
processes and causes the server to fork off new httpd children.
But again, if Apache::Reload runs as part of the child process itself,
how can it implement ReloadHttpds effectively? It would have to kill
itself off, which would mean your first request would generate an
error - not a good user experience.
