As for me, I locked myself to work on one thing: queueing. And I'm mostly
done.
A while ago I decided that the only way to get any real speed out of a
complex MLM written in Perl was to use some form of queueing with a
queue runner that sat around, pre-compiled, waiting for something to do.
And if you read comp.lang.perl.moderated you probably knew where I was
going.
So now I have a simple system:
The program that is called from the MTA is small. All it does is stuff
the message in a queue file and signal (or start) a master server. It
could be written in C.
A small persistent server oversees a pool of queue runners. This times
out after some period if inactivity.
A queue runner actually does the work. When signalled, it will run the
entire queue. It also goes away after some period of inactivity,
shorter than that of the master server. There is a (configurable)
limit on the number of concurrent runners.
This seems quite stable. It doesn't use any weird features; the enqueue
program just opens a socket and forks and the communication between the
runners and the server is done via pipes (no signals, no
multiple-accept-on-socket). Locking is via (Perl) flock.
This doesn't help the shell interface or any web stuff (which will require
a persistent server and some form of RPC) but it clears the last hurdle I
really needed: it can handle an offline user doing a mass delivery.
I'd still like to reduce the granularity by splitting up the act of posting
into a filtering step and a delivery step with separate queues for each
(since delivery can take so long), but right now there's plenty of testing
to be done.
This will go into CVS once I've made it configurable, perhaps tonight.
The queue runner is just another interface, so it will coexist with
non-queueing operation just fine.
- J<
Follow-Ups:
|
|
