[rabbitmq-discuss] rabbitmq-discuss Digest, Vol 28, Issue 39

[Nico Meyer]

Am Freitag, den 18.09.2009, 15:51 +0100 schrieb
rabbitmq-discuss-request at lists.rabbitmq.com:
> Hi, 
> 
> my boss wants me to explain why i want to choose RabbitMQ instead of Spread
> (http://www.spread.org/) or QWIDS (http://www.isti2.com/QWIDS/).
> Reason for him,  is that Spread and QWIDS are well used in other production
> environment,
> so, what rabbitmq can give more ?
> 
> 
> could you help me, thanks
> 

Hi Laurent,

I cannot say anything about QWIDS, but we recently switched from Spread
to RabbitMQ. The switch was mostly motivated by Spread's lack of
scalability and 'development momentum'. Let me elaborate both points a
little.
To scale the performance of a Spread ring you can add more nodes to the
ring. But each message is sent to every node, which is necessary because
of the very strong ordering guarantees that Spread gives you. Because of
this, it scales only for the number of consumers per message, not for
the number of messages. Also the latencies get really bad if you have a
lot of nodes and/or messages per second, because it uses a 'token' which
is passed around the 'ring' and only the node with the token can send
any messages to its clients.
To showcase the other point: about three or four years ago we stumbled
upon a very significant bug in Spread, which could completely disable
the whole Spread ring after some internal message counter wrapped around
(I believe after 2^32 messages). The only way to revive Spread in this
case, is to stop all nodes and restart everything. The first time this I
didn't get any answer on the mailing list. The second time, about 3
months later, someone pointed out a workaround, which had to be
performed manually before the counter reached its maximum value. Last
time I checked (about a year ago) there was no newer version or patch
available.

Besides from these problems, you also have to consider that the three
system are somewhat different in their architecture and have different
goals. Spread implements the Extended Virtual Synchrony model, which is
great if you wan't to maintain a shared state between clients, but is
inherently hard to scale. It gives you presence awareness and for
example a simple master election for free (by ensuring everyone gets
exactly the same join messages in the same order).

But on the other hand Spread does not queue messages or provide any
persistence. If you client disconnects for some time, all messages sent
during that time are lost (unless you implement it yourself with another
consumer). RabbitMQ has queueing and persistence out the box.

Also messages can only be 'routed' by an all or nothing key comparison
(much like a fanout exchange in RabbitMQ). Everyone who is member of a
group gets all messages sent to that group (and in the same order if you
want, but for a possibly large performance penalty). The AMQ model is
more flexible when it comes to routing.

One final thing I can think of is loadbalancing. Since with Spread
'everyone gets everything', the only way to do some kind of
loadbalancing is to selectively drop every Nth message, which is safe
because of the ordering guarantees. This might not be desirable if the
messages are large or otherwise costyl to send/receive. Also there is no
notion of transactions like in RabbitMQ. So if a consumer crashes after
receiving a message but before finishing whatever it needs to do with
it, it is not send to another consumer. You also have to implement that
yourself, should you need it.


I am sure there are more things to consider which I forgot. In the end
everything depends on the application you want to implement and the
requirements you have on the messaging system. Choose the messaging
model that fits best, and only then choose between different products.
End of smartass message!

Bye,
Nico

.