On Feb 14, 2005, at 10:40 AM, Martin Moss wrote:
I have a few thoughts on this... In my experience writing a daemon process is easy (well ish) but then configuring your system to manage them (have they died, have they crashed etc..) is more trouble than its worth.
Maybe -- although thttpd has a great wrapper script which I promptly "appropriated." It goes something like this:
#!/bin/sh
while true ; do
/usr/local/etc/apache2/perl/regend
sleep 10
doneIf regend ever exits, it's up again within 10 seconds -- no constant polling necessary. And the chances of a shell script this simple crashing are presumably quite small. The preforking process also does a good job of managing its children (it comes from Perl Cookbook recipe 17.12). However, firing up one regen server for every httpd child is taking up too much RAM, so I'm switching to a select() based server, a la recipe 17.13.
Is it possible to use some kind of cronjob based system, which runs a script every minute, picks up a list of things to process from say a database (which your Handler writes to, to communicate to the backend processes)...
The idea of storing a list of items which need updating in the db is appealing (that's how I handle RSS renders), but this does three things: it puts the weight of the "do we need to regen?" code back onto httpd, it delays regens for a minute, and it does those regens all at once, which could cause a slowdown every 60 seconds if the site gets busy. The way it works now is kind of nice, because if the user *knows* that a link should have shown up on a given page, they can hit "reload" and see the just-regenerated version.
- ben
