qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Wj <chris...@gmail.com>
Subject Re: Subject Filtering with Queues
Date Mon, 09 Jun 2014 12:39:42 GMT
Thanks for the detailed response. That makes a lot of sense. Can you (or
anyone) point me to a good document describing the 'link' and 'node' option
specification and potentially some more examples?

Tell me if I have this correct: The address field you used creates a sender
using AMQP 0-10 protocol and will send with a default subject of
'news.world'. Consequentially, because of the 'link' options, it will also
create a queue named 'worldnews' with a subject subscription (or routing
key binding?) to 'news.world'. This queue will be persistent even when this
sender disconnects and other senders/receivers can connect to it also.

-Chris



On Mon, Jun 9, 2014 at 5:26 AM, Gordon Sim <gsim@redhat.com> wrote:

> 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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message