RabbitMQ supports HTTP and has a clean easy API. Scales in lots of ways. Supports very high throughput on a single cheap AMI. Has awesome GUI and UI. Etc. YMMV.
"RabbitMQ could not enqueue/dequeue fast enough"? I think the STOMP plugin was still pre-production a year ago. You may want to try using RabbitMQ 3.x..
1. the results are from last year, and so not 100% representative of RabbitMQ 3.x which was released after these blogs were posted
2. what actually matters with message queue performance is stability and scalability over time .. testing this is extremely hard without making over-specific assumptions
Thanks for this lengthy reply. I'll try to keep mine short and that means skipping over a bunch of stuff.
First, re "whilst exchanges and bindings survive the loss of individual nodes, queues and their messages do not" -- this needs to be clarified. When queues are replicated, their messages do survive, in order, in the replica. The queue itself may die but the client can get back into context by finding another node in the group. This is observationally similar to DHTs.
Second, "a single logical broker" and "sounds an awful lot like a single element in the system that is responsible for message traffic".... NOOOOOO the point of 'logical' is the opposite of what you say!
Finally the BIG difference between DHTs and something like Rabbit is that in a DHT each datum is replicated around the ring N times, non-uniformly. Whereas in a system like Rabbit each datum is replicated N times in a uniform manner, such that ordered pairs of messages A and B will exist in every queue which has either A or B.
Paddy, thanks for asking me if I am "familiar with the basics" of a DHT. Just to be clear, I don't think DHTs are the same as messaging systems. But, they touch on a set of related issues.
My assertion was that "Just because software runs on multiple machines it does not mean that there is 'no SPoF'". You seem to have read this as saying "in all cases where there are multiple machines, there is always a SPoF". In any case, I was trying to make a more general point, which is that (A) lots of cases which seem to have no SPoF, in fact do have SPoFs, (B) some cases get accused of having a SPoF, but doing so is a mistake, and Rabbit is in this category because you can set up a number of multi-machine scenarios with the required redundancy, and (C) in many cases having a SPoF is not a problem anyway, and may even be a good thing.
You said "From what I can see in the docs, RabbitMQ is a client/server relationship. Meaning there is a server. Meaning a single point of failure and a bottleneck. I hate those..". With all due respect this represents a misunderstanding of Rabbit. Moreover you assert that 'there is a server' means that there is a 'single point of failure'. Because the conclusion does not follow from the premise, I assumed you must have meant something else.
Perhaps you could explain why you think your system has fewer 'bottlenecks' than RabbitMQ or other messaging systems. I don't think that it does but would love to be enlightened.
From your more recent comment, you seem to be saying that using a DHT is a good thing. Yes, I agree, sometimes this is the case. Are you familiar with how RabbitMQ does any of the following: clustering, HA, federation? You say that "Am I saying my solution is closer to what I want than RabbitMQ is? Yes. Yes I am.". I would love to understand this.
This does not make any sense. All software runs on machines. Each machine is potentially a 'single point of failure'. This sometimes is a problem, and sometimes is not.
Just because software runs on multiple machines it does not mean that there is 'no SPoF', for example in a distributed messaging system you need to replicate state, unless you don't mind losing it when you have a crash.
If you don't mind losing state, then it is very easy to run RabbitMQ on more than one server.
If you do mind losing state, then RabbitMQ provides several ways to use multiple servers in a decentralised and redundant manner. See eg http://www.rabbitmq.com/distributed.html
It is very easy to write a system with multiple components. The difficulty is preserving all the additional capability (eg uptime) while maintaining a coherent system. This role can be played by a "broker" which does NOT imply a single machine or "SPoF" - it can be a distributed service. See eg http://www.rabbitmq.com/blog/2010/09/22/broker-vs-brokerless...
Nice post. One way to delegate the Java client redirect is to use Spring AMQP for automatic connection failover. This has been available since 1.1.0 GA in May 2012.
For other languages, and in general, we are looking into ways to make the entire reconnect more transparent for cases both with and without intermediaries. Solving this at the protocol level and in the general case is non-trivial - you have to make some assumptions. Do please email the rabbitmq-discuss list if you want to talk about any of this.
So, why not just deliver that topology using off the shelf components? Rabbit, Kafka, ZeroMQ, ... the toolbox is deep. This is not meant as a criticism, I am simply trying to understand what I am missing when I look at your design :-)
Master-slave etc are HA techniques for replicating state eg queues (or "channels" as nsq calls them?). "Decentralized and distributed" has nothing to do with state, master/slave or any of that; it's a topological property of your system. You can certainly build a decentralized and distributed system using a set of brokers, regardless of whether they support HA.
I don't know what WebLogic can do for flow control exactly. Please email rabbitmq-discuss to get a definitive answer and discussion on what you can do with Rabbit, which supports various mechanisms.
RabbitMQ's main motivation has been to make it easier to join systems together, scale your applications and manage complex environments. That is what messaging is for. Back in 2006, we felt there was a need for a good, stable and scalable open source licensed product that could compete with the incumbents.
Notice that I did not mention performance. RabbitMQ has good performance and it is used quite a lot in finance, but the majority of users are what you might categorise as "anyone using MySQL or Postgres".
Re activemq vs zeromq, I recommend reading "broker vs brokerless" on our blog.
If you have any questions or problems involving RabbitMQ please email us ([email protected]) or post to the mailing list.
"one interesting concept about queues is contention and this is where RabbitMQ and others are behind"
Can you explain what this means? What kind of contention are you talking about. You say "RabbitMQ and others" - which others? Who implements this feature and what does it look like?
"you can't block a produced in RabbitMQ based on the number of messages on the queue"
Yes you can.
Well - it depends on your use case. RabbitMQ enables you to determine queue length, and supports flow control.
"a feature of the open source Erlang VM that's improved in the pay-for-support version"
Erlang was created by a telco in the 1990s and since then has been battered in production by serious users. It's real software. The version that Ericsson provide as open source is not crippleware as you seem to imply.
"RabbitMQ pays the performance cost of bouncing everything off the disk"
No it doesn't.
RabbitMQ only uses the disk if tell it to do so, eg if you require messages to be persisted when they cannot be delivered immediately.
"memory usage can grow and grow"
If you stuff data into a messaging server without draining it on the consumer side, then memory usage will grow. This will also happen if you write your messaging system in C++.
There are two solutions to this problem:
- flow control, where you tell producers to back off
- paging to disk, where you flush data from memory when it is on the disk
Neither of these is trivial to implement which is why there is a big gap between toy messaging systems and serious products.
As others point out on this page, RabbitMQ has support for both these features. In particular a lot of memory management capability has been added since 2.0.
But it's true that the community has been much more involved in clients like Pika, for example.
And yes we are planning to open up the bug tracker.
A piece of advice for anyone doing an open source project - start with an open tracker, because opening up a previously closed tracker is a royal pain in the butt.