On 12/22/2015 05:37 PM, Olivier Mallassi wrote:
not sure I got your question but I would answer : competing consumers
In fact, in AMQP 1.0,
- if I connect my consumer on a destination which is a topic, with
JMSSelector, this works but I get a subscription that I cannot share
between multiple consumers (so no load balancing). maybe it can work if I
do not use JMS but proton-j or an API that gives me access to the link
definition.
- if I connect to a queue, my JMSSelector is applied on the queue (which
fills up with the messages that do not match the selector)
on the other hand, if I do this in AMQP 0.10, this is almost straigh
forward: publish to headers exchange, bind your queues (config), then you
have competing consumers on each queues.
So, as I would like to continue using JMS as the API, I guess I was trying
to rely more on the broker capabilities to filter / route my messages. not
sure this is the good approach, btw.
Ok, understood. You can specify a selector as a queue option, which then
drops any messages routed to the queue that do not match the selector.
You can then combine that with any exchange level routing.
So e.g.:
qpid-config add exchange topic subjects
qpid-config add queue mysubscription --argument
qpid.filter="\"amqp.correlation_id\"='abc' AND color='blue' AND weight >
2500"
qpid-config bind subjects mysubscription mysubject
Then if you can consume from mysubscription using as many consumers as
you like, and any messages sent to 'subjects' where the subject is
mysubject and the selector matches, will be shared out between them.
(You could use a headers exchange instead of the topic exchange and do
some of the selection logic there, but the only reason to do so I think
would be if it were more efficient than the selector. I don't know
whether it would be as it hasn't been optimised much. The topic exchange
is the most efficient means of selection, so if the subject is
sufficient as a first level, that might work well).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
