[openamq-dev] round-robin queues

[Martin Sustrik]

Hi Terry

Terry Jones wrote:
> As I understand it, an AMQP exchange looks at the properties of an incoming
> message and its binding tables and decides which queues to forward copies
> of the message to. In our (little) experience, it looks like OpenAMQ broker
> (presumably as specified or implied by the AMQP spec) unconditionally sends
> the message to all queues whose bindings match the incoming message.
>
> Is that right?
>   
Exactly.

> Esteve is asking if it's somehow possible to have the broker use, for
> example, round-robin to select just one of the matching queues to send to.
>
> This seems like a useful thing to be able to do. It also seems like it
> shouldn't be hard to implement.
>   
Although this is not difficult to implement, there is a good reason not 
to do so. Actually, the load balancing in exchange would break the very 
idea of load balancing. There are two thing to take into account:

1. If a service instance is not connected at a moment the load balancing 
algorithm shouldn't block any messages and it should send them to 
running instances of the same service immediately.

2. If there is no running instance of a service, the messages should be 
queued until one becomes available.

After giving it a little thought you'll realise that load balancing 
should be done *after* the message is queued, never before (i.e. in the 
exchange).
> None of that seems unusual to me, so I still suspect that we're doing
> something fairly common and we're just not looking at it, or describing it,
> in terms that make sense to people who've been building these things for
> years.
>
>   
My feeling is that your I-1 model is exactly the way how the thing 
should be done. The only problem is the amount of resources you have. 
Such an amount would create a serious administrative bottleneck - both 
for human administrator who has to monitor/manage it and for OpenAMQ 
that would have problem to handle that many queues.

So, I expect, the whole thing is in some way simpler than that. Let me 
give an example:

Say the individual resources are managed by internet users and therefore 
there's no administrative problem with handling that many of them. 
However, there is not a huge amount of requests for most resources, for 
most of them it's one a day or so, so there is no performance problem 
involved.

However, some resources are heavily used and at that point the 
administrator has to interfere and make a replica of the resource on a 
different box. At this point the load balancing starts to make sense.

In the above example most resources have insignificant traffic and 
require no load balancing. However, there are few of them that are 
different and those need physical attention of the administrator 
(creating the replica).

Therefore, all the 'small' resources can be handled by a single queue - 
the single queue would create no problem as there is no load balancing 
going on anyway. (Actually, it will be one queue per box if the 'small' 
resources are distributed across multiple boxes.)

The 'big' (i.e. by-hand-administered) resources will have a queue each. 
That would allow for seemless load balancing across multiple boxes.

Ok, the above may not be exactly your case, but my point is that you 
should take the nature and performance profile of the resources into 
account rather than stating that 'we have 1,000,000 resources and we 
want the broker to handle them neatly non depending on whether there's 
one message a day or 100,000 messages a second.'

Does that make sense?

Martin