Re: Spread?

The Spread folks have done a great job of providing a basic (non-reliable,
publish-subscribe) messaging service with a straightforward API.  It's quite
comparable to the minimal products from the commercial messaging vendors
(I'm most familiar with Tibco's Rendezvous product, but MQSeries looks
about the same) - but you don't get any of the extras (message persistence,
format conversion tools, gateways to other protocols, management tools)
that are available from Tibco or IBM.

For one-to-one or one-to-many publishing, with message ordering, Spread
does just fine.

Message persistence is non-trivial, when you're dealing with messaging
across multiple machines.  There are many possible fault conditions where
you might not actually want message persistence to be guaranteed.  For
example, if the machine with the sending process goes down hard with a
message in transit, and takes a week to be recovered, do you still want
the message to be delivered?

If you absolutely want to guarantee your messages from point-of-origin to
point-of-receipt-and-processing, then put them in a database as Perrin
suggested.  Then you have to deal with the single point of failure of
your central database, performance, and so on.

My Spread::Queue module gives you a load-sharing solution ensuring
delivery of your message to exactly one of many receivers.  But the
message could still be lost along the way due to failures in various
parts of the system.

-Jason


Bas A.Schulte wrote:

> Hi,
>
> On Wednesday, November 27, 2002, at 07:42 AM, Perrin Harkins wrote:
>
>> I think message beans do sound attractive in this situation, and 
>> there is some infrastructure code to write here on the Perl side 
>> (putting messages in the database, reading them back out of it, 
>> triggering the appropriate handling code, and maybe throttling if you 
>> can find a way to make it generic enough).  It wouldn't be hard to 
>> make some modules that do what I described with cron, an RDBMS, and 
>> mod_perl, and that might be a good addition to CPAN.  Or maybe a 
>> generalization of Jason's Spread::Queue is in order.  People do seem 
>> to bring up messaging/queues a lot on this list.
>
>
> I would be interested in people's experience using Spread (from perl). 
> What are you doing with it from a functional point of view? How well 
> does it work? Likes/dislikes?
>
> I'm mostly interested in it being used for one-to-one or one-to-many 
> publishing of reliable/ordered messages.
>
> One other thing: from reading the docs it appears Spread itself 
> doesn't do persistent storage of messages (i.e. a receiver is 
> unavailable), Did you solve that? If so, how?
>
> Thanks for any feedback,
>
> Bas.
>
>
>