Dear Monks,

apologies for asking a not-strictly Perl-related question: I'm looking for a message system for a multi-server, multi-process system.

Running processes need to send messages to others for various reasons like "stop this work" or "here is my result".

We have two major scenarios:

1. A running task needs to receive a signal, something which could be done using Linux signals (like HUP, USR1, USR2) and kill() in a single-server environment. The receiving task may connect to the message server at startup and disconnect on exit. Messages may be checked by the process or delivered via callback but the process may not enter a "main loop" of another module because it's doing it's work in his own source.
2. We also have jobs running on a gearman cluster with a web-user waiting for results. The web-scripts usually poll the state of the gearman jobid and deliver the results once the worker is done. Each request is one status check and either result delivery or "no results" message to the client, the script exists once this is done and the browser issues a new request for the next check. Those check scripts can't stay connected and wait for messages but might "look for new messages" once per run.

I though about using our Memcached for message distribution but it's a cache and I don't like the idea that messages might get lost as a design specification (even if it's unlikely). Database is no option because it's way to slow, already heavy-loaded and I don't think that messages have to stay on various hard disks on a whole cluster because most of them won't life for more than a second.

Is there any reliable piece of software I'm missing? It doesn't need to be written in Perl but it must have a Perl-usable API (which should be no problem for network-based services).

Thanks,
Sewi