New User: Questions and Comments

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

New User: Questions and Comments

Cory G Watson
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
correctly.

Also, the method for specifying that the node should be a disk node is
confusing.  And I quote:

"we list rabbit@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@rabbit1 rabbit@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
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.

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
clunky.

***********

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
work!

--
Cory 'G' Watson
http://www.onemogin.com

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New User: Questions and Comments

Michael Bridgen-2
> 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@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@rabbit1 rabbit@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


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New User: Questions and Comments

Mark Steckel-2
Hi,

I am new to RabbitMQ as well. I've been reading about it for a while
but started my first RabbitMQ server just yesterday. So far I'm very
impressed.

On Apr 8, 8:16 am, Michael Bridgen <[hidden email]> wrote:

> > * 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.

Ahh, this is something I've been trying to understand as well...

Is it the case that a RabbitMQ cluster a) allows a queue to be
accessed from every node in the cluster, but b) the queue and the
messages it contains only reside in/on a single node?

> There is an HA guide on its way

I'm definitely interested in reading this.

Best
Mark

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: New User: Questions and Comments

Matthias Radestock-3
Mark,

Mark Steckel wrote:
> Is it the case that a RabbitMQ cluster a) allows a queue to be
> accessed from every node in the cluster, but b) the queue and the
> messages it contains only reside in/on a single node?

Correct.

>> There is an HA guide on its way
>
> I'm definitely interested in reading this.

It's still going through QA. Should be ready soon.


Regards,

Matthias.

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss