You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Chris Wj <ch...@gmail.com> on 2014/06/06 00:27:05 UTC
Subject Filtering with Queues
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.
Thanks,
Chris
Re: Subject Filtering with Queues
Posted by Gordon Sim <gs...@redhat.com>.
On 06/09/2014 01:39 PM, Chris Wj wrote:
> 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?
http://qpid.apache.org/releases/qpid-0.28/programming/book/section-addresses.html#idm223928811584
By no means complete, there are some examples on the wiki: Though
bhttps://cwiki.apache.org/confluence/display/qpid/Addressing+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.
Yes, in 0-10 the client establishes the 'link' from the exchange (i.e.
the 'node'), by creating and binding a queue (thus receiving the desired
messages that may be published to that node).
You can control details of the subscription queue (and indeed the
binding) over AMQP 0-10 using link options.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Subject Filtering with Queues
Posted by Chris Wj <ch...@gmail.com>.
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 <gs...@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
>
>
Re: Subject Filtering with Queues
Posted by Gordon Sim <gs...@redhat.com>.
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
Re: Subject Filtering with Queues
Posted by Chris Wj <ch...@gmail.com>.
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.
-Chris
On Fri, Jun 6, 2014 at 10:02 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 06/06/2014 02:16 PM, Chris Wj wrote:
>
>> 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.
>>
>
> So you want clients processing the same subject to compete for messages?
> I.e. a message for news.world would go to exactly one subscriber, not be
> copied to all?
>
> How dynamic do you need the subjects to be? Will a given client only ever
> process one subject, or might they process many? In the latter case would
> there be any relative ordering requirements?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Subject Filtering with Queues
Posted by Gordon Sim <gs...@redhat.com>.
On 06/06/2014 02:16 PM, Chris Wj wrote:
> 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.
So you want clients processing the same subject to compete for messages?
I.e. a message for news.world would go to exactly one subscriber, not be
copied to all?
How dynamic do you need the subjects to be? Will a given client only
ever process one subject, or might they process many? In the latter case
would there be any relative ordering requirements?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Subject Filtering with Queues
Posted by Chris Wj <ch...@gmail.com>.
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 <fr...@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
>
>
Re: Subject Filtering with Queues
Posted by Gordon Sim <gs...@redhat.com>.
On 06/06/2014 02:17 PM, Fraser Adams wrote:
> Gordon,
> Re "However, I am not sure whether the selector can select on the
> subject/routing-key"
>
> The spout and drain examples I posted earlier actually do work (using
> qpidd, I've not tried it with the Java Broker to be fair), but those
> were examples using AMQP 0.10
> e.g.
>
> ./drain -b localhost -f \
> "queue1; {create: receiver, link: {name: test-link, selector:
> \"qpid.subject='tim'\"}}"
>
> as you can see this is specifying a selector testing the qpid.subject
> property equals tim, which in AMQP 0.10 gets set automagically when I do
>
> ./spout -b localhost --content "Hello World" "queue1/tim"
>
>
> Because the subject (in AMQP 0.10) actually gets automagically mapped to
> qpid.subject (essentially an application property) this all does
> actually hang together with AMQP 0.10 using qpidd and qpid::messaging
> without "any handling of that as a special value"
Right, my point was your are matching against the qpid.subject
application property which is populated automatically by qpid messaging
clients (but wouldn't necessarily be for others, not sure what the 0-10
JMS client does for example).
> With AMQP 1.0 subject is an "immutable property" not an "application
> property" so uses its own accessor (you of course know this better than
> most :-)) so would need some code in the selector implementation to
> explicitly expose it for matching.
Right, and at present that isn't there as far as I can tell (though I
may just be missing it).
> You might well be right that the JavaBroker would reject this as invalid
> as a selector, I've been bitten by my use of hyphens in property names
> being rejected, but the qpid.subject definitely worked for me the last
> time I tried it on qpidd.
Ah yes, it was hyphens you had mentioned. I suspect the '.' may also be
a problem, since its not a valid char in a java identifier.
> Although not part of the JMS selector specification I do actually think
> that being able to use the subject as a pseudo-property for message
> selectors is pretty useful and something that I suspect most people
> might "intuitively" expect to be able to do.
I very much agree.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Subject Filtering with Queues
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Gordon,
Re "However, I am not sure whether the selector can select on the
subject/routing-key"
The spout and drain examples I posted earlier actually do work (using
qpidd, I've not tried it with the Java Broker to be fair), but those
were examples using AMQP 0.10
e.g.
./drain -b localhost -f \
"queue1; {create: receiver, link: {name: test-link, selector:
\"qpid.subject='tim'\"}}"
as you can see this is specifying a selector testing the qpid.subject
property equals tim, which in AMQP 0.10 gets set automagically when I do
./spout -b localhost --content "Hello World" "queue1/tim"
Because the subject (in AMQP 0.10) actually gets automagically mapped to
qpid.subject (essentially an application property) this all does
actually hang together with AMQP 0.10 using qpidd and qpid::messaging
without "any handling of that as a special value"
With AMQP 1.0 subject is an "immutable property" not an "application
property" so uses its own accessor (you of course know this better than
most :-)) so would need some code in the selector implementation to
explicitly expose it for matching.
You might well be right that the JavaBroker would reject this as invalid
as a selector, I've been bitten by my use of hyphens in property names
being rejected, but the qpid.subject definitely worked for me the last
time I tried it on qpidd.
Although not part of the JMS selector specification I do actually think
that being able to use the subject as a pseudo-property for message
selectors is pretty useful and something that I suspect most people
might "intuitively" expect to be able to do. I definitely think it'd be
good to have a consistent mechanism to enable this, as I say I was
intending to look at it 'cause it ought not to be too hard, but I've
been distracted on my JavaScript Proton port (though I can *finally* see
the light at the end of the tunnel on that :-)).
Frase
On 06/06/14 13:24, Gordon Sim wrote:
> Clarification:
>
> Over AMQP 1.0, the c++ qpid::messaging client will set a subject
> filter on link from the queue. The c++ broker will then treat that
> much like a message selector, except that it is a match against
> subject rather than anything more complex. On 0-10 the c++ client is
> like the python one, and the subject is ignored for a receiver.
>
> On 06/06/2014 11:48 AM, Fraser Adams wrote:
>> 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.
>
> You can certainly control the arguments sent in the subscription, and
> thus specify a selector to use.
>
> The c++ broker does now support selectors also, however the syntax is
> as defined for the registered AMQP 1.0 selector-filter (you can use it
> over 0-10 as well however) which is like the JMS syntax, but with a
> different convention for naming the special fields. The java broker
> supports the JMS selector syntax unmodified. The key used in the
> argument also varies. (This is something that would not be difficult
> to make more uniform and simpler).
>
> However, I am not sure whether the selector can select on the
> subject/routing-key. Looking at the c++ brokers code, I can't see any
> handling of that as a special value nor can I find anything in the JMS
> spec.
>
> Now, the qpid.messaging (and qpid::messaging) clients will set a
> qpid.subject header on messages they send, with the value being the
> subject on the message (which will be the subject specified in the
> sender address by default). So providing the messages were sent by
> those APIs, you could select on qpid.subject.
>
> However as Fraser has previously pointed out that is not a valid JMS
> name, so it may be rejected by the java broker(?) as invalid within a
> selector.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Subject Filtering with Queues
Posted by Gordon Sim <gs...@redhat.com>.
Clarification:
Over AMQP 1.0, the c++ qpid::messaging client will set a subject filter
on link from the queue. The c++ broker will then treat that much like a
message selector, except that it is a match against subject rather than
anything more complex. On 0-10 the c++ client is like the python one,
and the subject is ignored for a receiver.
On 06/06/2014 11:48 AM, Fraser Adams wrote:
> 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.
You can certainly control the arguments sent in the subscription, and
thus specify a selector to use.
The c++ broker does now support selectors also, however the syntax is as
defined for the registered AMQP 1.0 selector-filter (you can use it over
0-10 as well however) which is like the JMS syntax, but with a different
convention for naming the special fields. The java broker supports the
JMS selector syntax unmodified. The key used in the argument also
varies. (This is something that would not be difficult to make more
uniform and simpler).
However, I am not sure whether the selector can select on the
subject/routing-key. Looking at the c++ brokers code, I can't see any
handling of that as a special value nor can I find anything in the JMS spec.
Now, the qpid.messaging (and qpid::messaging) clients will set a
qpid.subject header on messages they send, with the value being the
subject on the message (which will be the subject specified in the
sender address by default). So providing the messages were sent by those
APIs, you could select on qpid.subject.
However as Fraser has previously pointed out that is not a valid JMS
name, so it may be rejected by the java broker(?) as invalid within a
selector.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Subject Filtering with Queues
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
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
Re: Subject Filtering with Queues
Posted by Gordon Sim <gs...@redhat.com>.
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