> Hello All! I'm a potential new user of RabbitMQ and am also new to
> AMQP and messaging in general.
Hi Cory, and welcome to the warren!
To the comments and questions:
> 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!
Painless set-up-and-get-going is a major driver for us, so it's good to
hear it was easy for you.
> * 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
> correctly.
Just to be clear, the flavour of a node in a cluster has no bearing on
delivery mode -- persistent messages are always persisted. What's being
saved to disk in a disk node is durable exchange, queue and binding
configuration and cluster configuration.
Yes, it would be better if "rabbitmqctl status" listed whether the
running nodes were disk or RAM nodes, at least for verifying
configuration, as you say. I've logged a bug here for it.
> 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"
Yes it is, and it doesn't help that both "rabbitmqctl" and "man
rabbitmqctl" give slightly the wrong syntax (we fixed that just now).
> 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?
Yes that's exactly it. "man rabbitmqctl" does give a better account
than the web site guide, but it's still rather obscure.
> 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 rabbit1rabbit at rabbit3[type="disk"]
>> or whatever is easiest to parse.
Well, the idea is that at the point you are issuing the command you can
specify only the diskiness of the local node. So perhaps better would
be a switch:
rabbitmqctl cluster [--disk | -D] <clusternode> ...
(bug logged for this too)
> * Cluster Capabilities *
> [...]
> 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
> happen:
> * 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.
Indeed. The single most common misunderstanding about clustering that
comes up is that it gives full redundancy, whereas it's for scalability
(basically, being able to have more processors accepting, routing, and
delivering messages). So the guide should at least say that up-front.
There is an HA guide on its way -- consider your voice added to those
willing it onward.
> 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?
Yes, there's no difference, observable by a client, between the queue
being deleted by another client and it disappearing because it's located
at a downed node. There's not really a mechanism in AMQP to describe
unavailability as such; and anyway, in an ideal world downing a node
wouldn't have that effect.
> * 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!
http://www.rabbitmq.com/how.html links to blog posts and so on with
plenty of examples; in particular,
http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/ seems to be
popular as a primer.
I don't there's a single place with common recipes (e.g., on the
RabbitMQ site) -- that's a great suggestion.
> * 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
> clunky.
There's no AMQP-specified way of doing this, but you could look at BQL
as a way of maintaining a repeatable configuration:
http://www.rabbitmq.com/rabbitmq-bql.html
> 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.
For sure, and thank you for yours, they have indeed been a help.
Regards,
Michael