[Catalyst] A Perl Message Queue?

Brandon Black blblack at gmail.com
Thu Aug 23 15:58:55 GMT 2007

On 8/23/07, Mark Knoop <mark at rawcane.net> wrote:
> > Don't use a DB as the backing store for a message queue if you will ever
> > need to pass a lot of messages thought it - you're just asking for
> > trouble doing it that way.
> >
> Getting way off topic but, understanding the kind of trouble one can get
> into using a DB to store messages, how else can one ensure data is always
> recoverable should the app bomb out?

That's why one normally doesn't implement a message queue from
scratch, but instead uses an off the shelf one (same deal as
databases).  Message queueing systems vary (again, much like
databases) in what features they support.  Reliable messaging
transactions, or just "best effort"? Local-only, or networked?
Disk-backed, or memory-only (are messages lost if they machine
randomly reboots)?  Single-hop messaging events, or does the system
actually track larger-scale transactions that encompass several
different queued messages between different components over time?  If
transactional, does it integrate with your database's transaction
system?  Can messages only have one receiver, or can they be

To give some idea, here's a couple of common products in the commercial world:

IBM's MQSeries (now called WebSphere MQ)

BEA MessageQ:

If you search CPAN Distributions for the word Queue, you get 35 hits
that range all over the feature map for a queuing system, including
interfaces to some of the commercial systems.

-- Brandon

More information about the Catalyst mailing list