[rabbitmq-discuss] New User: Questions and Comments
jheephat at gmail.com
Thu Mar 11 14:07:51 GMT 2010
Hello All! I'm a potential new user of RabbitMQ and am also new to
AMQP and messaging in general.
Let me begin by congratulating you all on creating an excellent
package with a great community. Having looked at a lot of messaging
I'm fairly confident saying that RabbitMQ is at the top of the heap.
It all depends on your needs, of course, but RabbitMQ is near the top
of the list in all categories.
That being said I have the disadvantage of being a complete noob with
RabbitMQ. I also have the exciting job of explaining and justifying
the use of messaging to my CTO, System Administrators and Developers.
As such I've taken some time to compile a list of comments and
questions that may help you help people like me in the future.
* General *
RabbitMQ is easy to set up, requires less configuration and works well
right out of the box. It's also available in our distribution of
choice (Debian) which makes things easier. Thanks!
* Cluster Setup *
Setting up a cluster works great but the status of a node as a disk
node is confusing. This was exacerbated by problems I was having with
my client library not setting the delivery mode. Regardless, I don't
see a way to determine (from rabbitmqctl) if a node is a disk node or
memory node. It's therefore difficult to tell if I've set things up
Also, the method for specifying that the node should be a disk node is
confusing. And I quote:
"we list rabbit at rabbit3 as a node in the cluster command in order to
turn it into a disk rather than ram node"
I still don't grok that. It sounds like when specifying the other
nodes this node should talk to, if we specify ourselves then it
becomes a disk node? I'm not sure if there's some cultural/technical
reason for this type of configuration but it is completely lost on me.
I'd be much more likely understand something like
rabbitmqctl cluster rabbit at rabbit1 rabbit at rabbit3[type="disk"]
or whatever is easiest to parse. I'm assuming the existing mechanism
is in place because the list of nodes is a list and therefore
specified as such. Regardless, it's difficult for me to follow.
It would also be great if the node's status as memory or disk was
shown in rabbitmqctl status.
* Cluster Capabilities *
This paragraph in the docs caused me lots of trouble:
"All data/state required for the operation of a RabbitMQ broker is
replicated across all nodes, for reliability and scaling, with full
ACID properties. An exception to this are message queues, which
currently only reside on the node that created them, though they are
visible and reachable from all nodes. Future releases of RabbitMQ will
introduce migration and replication of message queues."
When I originally read this I said "great!" and moved right down the
page to setup my cluster. I was not really aware that this would
* Create queue A on node 1
* Send messages that are routed to queue A
* Pull the plug on node A
* Node 2 (if asked) says queue A doesn't exist
I realized afterward that this was what the earlier quote was trying
to tell me. I'm not sure how to solve it in language. There's a thin
line between warning users of shortcoming and being an alarmist.
I imagine that one could watch for the error saying that the queue
doesn't exist and retry later. But how does one disambiguate this
from the unlikely occurrence that the queue has somehow disappeared?
Perhaps if I had asked node 2 about queue A it could've told me that
is was unavailable rather than non-existant?
* Patterns *
I've watched the RabbitMQ Google tech talk opened by Alexis and would
love to see some recipes for setting up RabbitMQ to satisfy the
various patterns outlined. Things like Service Bus, Client Server,
etc. Having that as a guide would be great!
* Configuration *
Is it possible to specify exchange/queue/binding creation in
configuration? If not, I'm going to need to write a client
application that connects and establishes them for me. That seems
I hope that me pointing out a mole or two on your baby doesn't sound
like I'm implying that the whole thing is ugly! Users rarely realize
that the BEST time to make comments about a complex system such as
this is when they are most confused. I hope that discussing this can
help remove this barrier for other users. Thanks for all the great
Cory 'G' Watson
More information about the rabbitmq-discuss