perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Siracusa <sirac...@gmail.com>
Subject Re: a better way to recognize module changes
Date Fri, 11 Sep 2009 23:10:27 GMT
On 9/11/09 6:57 PM, Jonathan Swartz wrote:
>> 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.

The last thing I did in this area looked something like this:

  PerlCleanupHandler My::WebApp::Restarter
  PerlSetVar WatcherInterval 60
  PerlSetVar WatcherCompileCheck 1

where all the handler did was fork off a watcher process if one didn't
already exist.  The watcher would then stat() all the files in %INC
periodically.  If one had changed, it'd attempt to compile it (if
WatcherCompileCheck was true) catching/absorbing any errors to prevent ugly
output, and then restart the apache server by sending it a signal if the
file compiled okay.

Doing a full restart avoids all the odd module re-load issues (and there are
many).  The polling interval may seem too long, but this would all happen as
you were working on the code and before you reached back to a browser window
to reload a page.  By the time you did, the hope was that the server would
already be back up again.

One obvious improvement would be to use kqueue/inotify/FSEvents to avoid
polling entirely, making it much more likely that the server would be back
in time for your next request.

-John



Mime
View raw message