[rabbitmq-discuss] New User: Questions and Comments

Thu Apr 8 13:16:27 BST 2010

> 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 rabbit1 rabbit 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