5 ms·

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 specifi

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 17y ago
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 17y ago
  I'm not down-modding you, but I am using AMQP in production on http://tweeteorites.com/ 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/ 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 17y ago
    That is actually a very valid question - anyone know the stack similar to rabbitmq server + celeryd , but built around zeromq ?
    - deleted 17y ago
      [deleted]
    - rabbitmq 17y ago
      Since ZeroMQ has no broker but is peer to peer, that would be somewhat unnatural. Cheers alexis
- rabbitmq 17y ago
  Hi, Alexis here from RabbitMQ. Wtf? You may not like what we do with AMQP but I can assure that lots of people are very happy using it in its RabbitMQ incarnation. Which version of AMQP have you "had the misfortune to work with" and how have you found it "hopelessly overengineered"? Is there something else you would recommend - and if so why? We do actually like making our product better and appreciate constructive criticism. Please do explain. Also please note that RabbitMQ supports multiple protocols and one reason we like AMQP 0-8 and 0-9-1 is that they are flexible enough to make this easy (see e.g. RabbitHub on Github). Cheers alexis
  - moe 17y ago
    Oh interesting to hear from a RabbitMQ developer, thanks for taking the time to reply. Well, I'll try to elaborate on my rant. Most of it from memory (been a year ago since I last touched AMQP). Back then when I looked at AMQP (and used it for one project): * It was very hard to find reasonable documentation. The most accessible I found was the (excellent) http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/ http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/ blog post. This was what eventually got us off the ground. Imho a testament to the shortcomings of the "official" documentation (where is it?). * RabbitMQ only implemented AMQP 0.8. I cannot remember the exact differences between 0.9 and 0.8 (and heck, good luck trying to find a document explaining them even today). For us it boiled down to some clients simply not working and it took a while to figure out what the problem even was. * Client interoperability was generally spotty, even in clients supposed to be compatible. It seems the idea of that whole spec-file stuff was to make the protocol pluggable and flexible. However the only thing it seems to have achieved is to make client development hell. The client we eventually went with (py-amqplib) doesn't even use the spec-file because "parsing takes too long". * Moreover the sheer existence of http://www.rabbitmq.com/interoperability.html http://www.rabbitmq.com/interoperability.html is a testament to a flawed protocol. If I can't rely on a 0.8 client to talk to a 0.8 server properly, then something is fundamentally wrong. * There's a huge pile of semantic baggage (Exchanges, Bindings, Queues, Channels) that left us with a giant "WTF" the more we used it. Yes, it can be made work. But hell, talk about overengineering. Much simpler constructions could have been used to achieve the same goals. * As I just learned during my googling for this post, apparently some of the problems have even been acknowledged by the officials and are supposed to be simplified in AMQP 1.0 (http://www.amqp.org/confluence/display/AMQP/Background+to+AMQP+1-0 http://www.amqp.org/confluence/display/AMQP/Background+to+AM...). But I'm not expecting much, to be honest. So, that's just a few points that popped into my head immediately, there's more if I'd dig deeper. It's just a fundamentally bad protocol if I have ever seen one, and I'm honestly surprised to see people defend it even after the creators themselves (iMatix) acknowledge it to be a dead-end. To put it from an different angle: When you think about what AMQP really does then how long would it take you to whip up a near-trivial but feature-equivalent protocol from scratch? I could think of many ways to skin that cat in a better way, with a simple, hackable, plain-text protocol. You know, one of those protocols where I, as a developer, can even sniff and see what is going on at any time. Those are possible, as demonstrated by redis, memcached, STOMP, beanstalkd and many others. I acknowledge that some complexity is unavoidable for advanced use-cases. Still, a good protocol layers the complexity in a way so that simple stuff remains simple and complex stuff becomes manageable. To me AMQP is a complete failure in both regards; you are confronted with the full complexity even for the most trivial use-case. And it seems for complex use-cases it adds a hefty layer of complexity of its own, rather than helping to wrap up.

moe 17y ago

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 17y ago
I'm not down-modding you, but I am using AMQP in production on http://tweeteorites.com/ 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/ 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 17y ago
  That is actually a very valid question - anyone know the stack similar to rabbitmq server + celeryd , but built around zeromq ?
  - deleted 17y ago
    [deleted]
  - rabbitmq 17y ago
    Since ZeroMQ has no broker but is peer to peer, that would be somewhat unnatural. Cheers alexis
rabbitmq 17y ago
Hi, Alexis here from RabbitMQ. Wtf? You may not like what we do with AMQP but I can assure that lots of people are very happy using it in its RabbitMQ incarnation. Which version of AMQP have you "had the misfortune to work with" and how have you found it "hopelessly overengineered"? Is there something else you would recommend - and if so why? We do actually like making our product better and appreciate constructive criticism. Please do explain. Also please note that RabbitMQ supports multiple protocols and one reason we like AMQP 0-8 and 0-9-1 is that they are flexible enough to make this easy (see e.g. RabbitHub on Github). Cheers alexis
- moe 17y ago
  Oh interesting to hear from a RabbitMQ developer, thanks for taking the time to reply. Well, I'll try to elaborate on my rant. Most of it from memory (been a year ago since I last touched AMQP). Back then when I looked at AMQP (and used it for one project): * It was very hard to find reasonable documentation. The most accessible I found was the (excellent) http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/ http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/ blog post. This was what eventually got us off the ground. Imho a testament to the shortcomings of the "official" documentation (where is it?). * RabbitMQ only implemented AMQP 0.8. I cannot remember the exact differences between 0.9 and 0.8 (and heck, good luck trying to find a document explaining them even today). For us it boiled down to some clients simply not working and it took a while to figure out what the problem even was. * Client interoperability was generally spotty, even in clients supposed to be compatible. It seems the idea of that whole spec-file stuff was to make the protocol pluggable and flexible. However the only thing it seems to have achieved is to make client development hell. The client we eventually went with (py-amqplib) doesn't even use the spec-file because "parsing takes too long". * Moreover the sheer existence of http://www.rabbitmq.com/interoperability.html http://www.rabbitmq.com/interoperability.html is a testament to a flawed protocol. If I can't rely on a 0.8 client to talk to a 0.8 server properly, then something is fundamentally wrong. * There's a huge pile of semantic baggage (Exchanges, Bindings, Queues, Channels) that left us with a giant "WTF" the more we used it. Yes, it can be made work. But hell, talk about overengineering. Much simpler constructions could have been used to achieve the same goals. * As I just learned during my googling for this post, apparently some of the problems have even been acknowledged by the officials and are supposed to be simplified in AMQP 1.0 (http://www.amqp.org/confluence/display/AMQP/Background+to+AMQP+1-0 http://www.amqp.org/confluence/display/AMQP/Background+to+AM...). But I'm not expecting much, to be honest. So, that's just a few points that popped into my head immediately, there's more if I'd dig deeper. It's just a fundamentally bad protocol if I have ever seen one, and I'm honestly surprised to see people defend it even after the creators themselves (iMatix) acknowledge it to be a dead-end. To put it from an different angle: When you think about what AMQP really does then how long would it take you to whip up a near-trivial but feature-equivalent protocol from scratch? I could think of many ways to skin that cat in a better way, with a simple, hackable, plain-text protocol. You know, one of those protocols where I, as a developer, can even sniff and see what is going on at any time. Those are possible, as demonstrated by redis, memcached, STOMP, beanstalkd and many others. I acknowledge that some complexity is unavoidable for advanced use-cases. Still, a good protocol layers the complexity in a way so that simple stuff remains simple and complex stuff becomes manageable. To me AMQP is a complete failure in both regards; you are confronted with the full complexity even for the most trivial use-case. And it seems for complex use-cases it adds a hefty layer of complexity of its own, rather than helping to wrap up.