[openamq-dev] round-robin queues

[Terry Jones]

>>>>> "Martin" == Martin Sustrik <sustrik at imatix.com> writes:

>> 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?

Martin> Exactly.

OK, great.

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

Martin> Although this is not difficult to implement, there is a good reason
Martin> not to do so. Actually, the load balancing in exchange would break
Martin> the very idea of load balancing. There are two thing to take into
Martin> account:

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

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

Martin> After giving it a little thought you'll realise that load balancing
Martin> should be done *after* the message is queued, never before (i.e. in
Martin> the exchange).

I've given it a little thought, but I really don't understand :-)

In your 1, what's the difference between sending to all matching queues and
sending to just one? I don't see what that has to do with blocking.

I don't see what your 2 has to do with the difference between sending to
all relevant queues or just picking one. As I'm thinking of it, there is no
queue in this case - it's the running services that create the queues.

Sorry if this sounds dense or like me being difficult - I really don't get
it.

Martin> My feeling is that your I-1 model is exactly the way how the thing
Martin> should be done. The only problem is the amount of resources you
Martin> have.  Such an amount would create a serious administrative
Martin> bottleneck - both for human administrator who has to monitor/manage
Martin> it and for OpenAMQ that would have problem to handle that many
Martin> queues.

We agree that in an ideal world I-1 would be the way to go. But we also
agree that in practice it's not going to scale.

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

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

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

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

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

I agree with all this, but it doesn't seem to move me towards a practical
solution.

For example, suppose I want to interact with resource r1. Do I need to
maintain and consult some database table that tells me which queue that
resource is currently available on?  That puts the work of maintaining and
deciding where to route messages to onto my code - which seems wrong
because that's precisely what you use something like AMQP for.

We have also talked about something like your approach. In it, we would
keep a table that indicates which boxes (i.e., queues, seeing as this would
be a 1-queue-per-box setup) hold which resources. So if you have a resource
on box 1 which creates and listens on queue 1, and you replicate it onto
box 2 (listening on queue 2), then you also tell another box or process
that r1 is now also available on q2. To obtain service for r1 a client
would then ask which queues r1 was on, get an answer of (q1, q2) and choose
one at random.

That would work. BUT..... why should we do that work?  Isn't that exactly
the kind of work a messaging hub is explicitly designed to do?

Maybe there's something in all this about blocking that I don't understand.

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

We do take this into account. Resources that are not being used can be
taken offline. Resources that are heavily used can be replicated. Resources
that are lightly used can all live on the same box. Resources that are big
can live on their own box. Etc.  All that can be automated.  The question
is: when we have a resource r1 replicated on several boxes, can we use AMQP
to round-robin messages to those boxes?

It looks like the answer is no; that we should be doing that work ourselves
at the other end of the queue. I just don't understand why that's a better
solution.

Thanks again for your patience!

Terry