

Head dev of RabbitMQ response to OpenAMQ's announcement - liraz
http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2010-March/006754.html

======
dschobel
Not much by way of technical content. Although when the original charge is
that the protocol is "fundamentally flawed", I don't know how you can respond
specifically beyond saying "it works and people are using it" (which it seems
to and which they are).

~~~
moe
You could say: "Yes, you are right. We, too, have noticed what huge pile of
hopelessly overengineered garbage it is. Thanks for admitting your own
mistake, so glad we can finally get rid of this monstrosity and move on to
something sane."

This would be the automatic response from anyone who has had the misfortune to
work with AMQP, thus I'm a bit baffled the RabbitMQ guys want to stick with
it.

Edit: And yes, I'm not really surprised that I'm getting modded into oblivion.
Still, would the downvoters mind to elaborate on what kind of exposure they've
had to AMQP and what part of it they consider worth keeping?

~~~
wooster
I'm not down-modding you, but I am using AMQP in production on
<http://tweeteorites.com/> with RabbitMQ.

I need persistence and flow control, as my consumers are unreliable and
production rate is highly variable. This will become even more important as
some of the new Twitter data streams come online.

It took me about 2 days to completely reengineer my backend around RabbitMQ
and a custom daemon to serve stream requests. Granted, I already had RabbitMQ
set up and routing background tasks for celery ( <http://celeryproject.org/>
), but it's still pretty trivial to set up and get running. The easy case,
which I'm at now, is pretty easy, and I've got a good path to scalability with
fan out exchanges.

That said, faster is better, and I'd be interested in zeromq if they had some
of the features I need.

~~~
sandGorgon
That is actually a very valid question - anyone know the stack similar to
rabbitmq server + celeryd , but built around zeromq ?

~~~
rabbitmq
Since ZeroMQ has no broker but is peer to peer, that would be somewhat
unnatural.

Cheers

alexis

------
andrewcooke
ok, i am a bit clueless here, but if 0mq has no persistance, how is it
reliable (durable)? or, if it's not reliable (durable), isn't this whole
debate comparing apples and oranges?

[edited to clarify i am talking about durability and not just reliability in
the tcp sense]

~~~
dschobel
You are correct, there is no persistence. 0MQ is basically just a step above
socket level communications, while obviating all of the tedious BS socket
programming forces you to do.

Here's a good intro to 0MQ from lwn.net, along with sample code:
<http://lwn.net/Articles/370307/>

~~~
andrewcooke
thanks. this seems an awful lot like the nosql "debate" in that the two
"sides" (typically) have different priorities (and the differences are
similar, related to consistency and scaling).

[and also makes imatix not look that good, if any customers need the
durability part, which is quite a common requirement]

------
seldo
This doesn't address 0MQ's performance improvement claims, which I would have
thought was the biggest thing the RabbitMQ guys would want to address.

~~~
evgen
If you don't need to provide persistence and flow control it is amazing how
much faster you can go...

~~~
majke
And if you do, things can became pretty complicated.

~~~
evgen
Absolutely. I happen to need these bits so zeromq is a non-starter for me. I
am mildly annoyed by the "we are faster" rhetoric without the "but we only
support a small subset of the useful things you can do with a message queue"
caveat, but it is a mostly meaningless bit of marketing so I can let it slide;
anyone who really needs those sorts of speeds knows how to actually evaluate
products and is unlikely to be suckered by a false dichotomy setup like the
one on the zeromq home page.

