On 06/06/2014 03:11 PM, Chris Wj wrote:
Yes, competing for messages, like a task queue with multiple workers.
I want to have N workers. Any worker knows how to process M kinds of
messages (identified by subject, or queue name). For now, N = M, but I
foresee that it will not in the future. I want to make sure I can enqueue a
job with highest priority that will be taken by the next available worker
for that subject. The subjects wont be changing often. They are categories
that we can manage over time. Having dynamics subjects would be great, but
we can manually create a queue for a subject if need be.
Manual configuration is usually the most portable option. However if you
keep your sender and receiver addresses configurable, then its easy to
adapt.
To have a shared queue created (and bound) on-demand, shared by multiple
receivers and not deleted when there are no receivers, you could use
something like the following with your receivers:
'amq.topic/news.world; {link:{name:worldnews,
x-declare:{auto-delete:False, exclusive:False}}}'
on the sending side you can then send either to amq.topic, setting the
subject of messages as desired, or if you like you can create a sender
of a specific subject e.g. amq.topic/news.world and it will set the
subject for you by default.
Now, when you say 'forward compatible', my one concern is that at
present the pure python qpid.messaging library is AMQP 0-10 only. That
pretty much limits it to one of the Qpid brokers.
There is a swig wrapper for the c++ version of that api that is very
close. We use it for testing as it can speak either 0-10 or 1.0.
Ideally for forward compatibility, you would want something that can
speak AMQP 1.0. Not because the 0-10 support is going to be removed, but
because it gives you more options.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
