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 Fri, 06 Jun 2014 13:16:52 GMT
Actually, I have experience using RabbitMQ, which uses 0.9.1. This is my
first time working with QPID. I'm trying to figure out the most forward
compatible (c++ or java broker) way for client programs to ensure that the
exchange and queues that receive certain types of message are created and
durable. My desired pattern is to have a job queue that can be sent
messages with routing keys or subjects that can be filtered (IE.
news.sports, news.world, etc.) and have one for priority as well (IE.
consume from the priority queue first, then the normal task queue),
Although I recently noticed the priority queue support and I think that
would be great to utilize.

Basically I want the clients to be able to take tasks with a given subject,
but first take the highest priority tasks.

-Chris


On Fri, Jun 6, 2014 at 6:48 AM, Fraser Adams <fraser.adams@blueyonder.co.uk>
wrote:

> On 06/06/14 09:58, Gordon Sim wrote:
>
>> On 06/05/2014 11:27 PM, Chris Wj wrote:
>>
>>> It seems that subject filtering with queues is not working in the current
>>> qpid implementations. What is the recommended way to simulate this
>>> behavior? I am used to AMQP 0.9.1 and I am very unfamiliar with creating
>>> such filtering behavior with QPID. I would like to programmatically
>>> establish queues and set it up so that receivers can specify a
>>> key/subject
>>> that matches messages. I'm primarily using Python and would like to keep
>>> things as cross platform as possible.
>>>
>>
>> With the qpid.messaging API (which I assume is what you are using?), you
>> can specify an address for your receiver in the form <exchange>/<key>
and
>> the library will create a queue for you and bind it to the specified
>> exchange with the specified key.
>>
>> So e.g. creating  a receiver for 'amq.topic/abc' will then receive
>> messages sent to amq.topic with the routing key being abc.
>>
>> If you want you can control the 'subscription queue' created in more
>> detail by specifying some link options.
>>
>> E.g. 'amq.topic/abc; {link:{name:my-queue}}'
>>
>> would mean the queue was given the name my-queue. Further you can specify
>> details of the declare used to create the queue if needed.
>>
>> E.g. 'amq.topic/abc; {link:{name:my-queue, x-declare:{auto-delete:False,
>> durable:True}}}'
>>
>> In these examples, the filtering is applied to messages coming through
>> the exchange, before they are enqueued.
>>
>> If on the other hand you use an address where the 'node' is a queue, i.e.
>> <queue>/<key>, then for receivers the key will not have any effect with
the
>> current qpid.messaging. That pattern implies filtering by subject on the
>> messages after the have been enqueued. [It is now supported by the c++
>> qpid::messaging (when used with qpidd, the c++ broker), but not by the
>> python qpid.messaging equivalent.]
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
> Hi both,
> Rob Godfrey is probably better placed to answer this but given Chris's
> original mail where he says "I am used to AMQP 0.9.1" I'm guessing that
> he's actually using a python client with the Java Broker - is that correct
> Chris?
>
> On the subject (pun!!) of "If on the other hand you use an address where
> the 'node' is a queue, i.e. <queue>/<key>" if that's the behaviour that is
> actually required (though I'd personally use the exchange/queue approach) I
> *wonder* if it could be achieved via message selectors. I know that
> selectors were mostly introduced as part of the AMQP 1.0 work but I know
> that Rob has plenty of users using older versions of AMQP and I think that
> his intention is to have the Java broker honour as much as possible (he
> even intends to allow older versions talk to AMQP 1.0 Management nodes).
>
> So I can't say for sure, but if the Java broker honours message selectors
> for older AMQP versions it *might* be possible to do something like
>
> ./drain -b localhost -f \
> "queue1; {create: receiver, link: {name: test-link, selector:
> \"qpid.subject='bill'\"}}"
>
> ./drain -b localhost -f \
> "queue1; {create: receiver, link: {name: test-link, selector:
> \"qpid.subject='ben'\"}}"
>
> ./drain -b localhost -f \
> "queue1; {create: receiver, link: {name: test-link, selector:
> \"qpid.subject='tim'\"}}"
>
> ./spout -b localhost --content "Hello World" "queue1/tim"
>
>
> The main gotcha is I think the subject. AMQP 0.10 (not sure about 0.9.1)
> uses qpid.subject but for AMQP 1.0 the subject is in a standard header not
> a user property and I don't think that there's *currently* a way to apply a
> message selector to that, so if you are planning on using 1.0 or trying to
> interoperate between versions there are still some wrinkles with this sort
> of pattern. I've been meaning to look at that but I've been tied up on
> other things.
>
> As I say I'd tend to follow Gordon's suggestion around using the
> exchange/binding/queue pattern, but the queue/selector pattern definitely
> works on recent Qpid versions (I've no idea about performance implications
> between the two approaches, but Gordon's approach is much more the common
> tried and tested pattern to I'd bet that there'd be fewer gotchas!)
>
> Regards,
> Frase
>
>
>
> ---------------------------------------------------------------------
> 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