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: [email protected]
For additional commands, e-mail: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
