You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Olivier Mallassi <ol...@gmail.com> on 2015/12/21 18:02:02 UTC
[C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Hello
While using C++ Broker (0.34) and JMS Selector (JMS 0.7.0) I observed two
things:
1/ the JMSSelector filter cannot use the JMSCorrelationID header but must
use the amqp equivalent header. so my selector is
messageConsumer = session.createConsumer(queue,
"\"amqp.correlation_id\"='abc' AND color='blue' AND weight > 2500");
//JMSCorrelationID='abc' AND color = 'blue' AND weight > 2500");
2/ the messages that does not match the filter stay in the queue (broker
side).
qpid-stat gives me this (300 unconsumed messages)
queue dur autoDel excl msg
msgIn msgOut bytes bytesIn bytesOut cons bind
==========================================================================================================================
aa9f75f7-a42f-4c97-96f6-ea12a61d6820:0.0 Y Y 0 0
0 0 0 0 1 2
A *300 *1.70k
1.40k 68.1k 381k 313k 0 2
B 1.70k
1.70k 0 381k 381k 0 0 2
Behind the scene, queues are binded to a topic exchange.
Based on this discussion, the JMSCorrelation ID should be ok in the next
release: https://issues.apache.org/jira/browse/QPID-6714
Why do messages stay in the queue server side? related to
https://issues.apache.org/jira/browse/QPID-5030?
Am I missing something?
Cheers.
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Olivier Mallassi <ol...@gmail.com>.
hum. regarding the auto-delete, looks like this is my fault.
I changed my JMS code to explicitly use a temp queue
TemporaryQueue tmpQueue = session.createTemporaryQueue();
messageConsumer = session.createConsumer(tmpQueue, "msg selector....")
and then the queues are created as auto delete
temp_rcv_qpid-jms:temp-queue-creator:ID::48e3b12c-a7f8-42cf-b499-168ddda7546a:1:1
auto-del
do not need to use the QueuePolicy
On Tue, Dec 22, 2015 at 10:50 AM, Olivier Mallassi <
olivier.mallassi@gmail.com> wrote:
> - I am using session.createConsumer(myTopic, "messageSelector") so AFAIK,
> it is not durable subscription. I was also reading
> http://qpid.2158936.n2.nabble.com/Autodelete-queues-not-deleted-td7633221.html
> and the QueuePolicy. Not sure how it maps to the jms destination name
> (maybe the jms.queueprefix) but maybe that can help
>
> - indeed JMS 2.0 defined shared subscription. Anyway, maybe during that
> time I need to rely on AMQP 0.10 bindings (within the broker) to have
> queues on which consumers can compete.
>
>
>
> On Tue, Dec 22, 2015 at 10:39 AM, Gordon Sim <gs...@redhat.com> wrote:
>
>> On 12/22/2015 09:22 AM, Olivier Mallassi wrote:
>>
>>> by the way, wen I consume from a node that is a topic, the JMS / AMQP 1.0
>>> creates a queue with an uniqueID for each receiver (e.g.
>>>
>>> MyComponent_qpid-jms:receiver:ID::3008640b-8ac6-4c87-9485-6156773c79b7:1:1:1:payments)
>>>
>>
>> Actually that queue is created on the broker side. The name comes from
>> the container id and link name.
>>
>> - is there a way to auto-delete this "queue" when the consumer JVM shut
>>> down?
>>>
>>
>> It should be auto-deleted by default, unless the client requests
>> otherwise. Is it a durable subscription on the topic that you created?
>>
>> - is there a way to share this "queue" between multiple consumers so that
>>> they can compete each other?
>>>
>>
>> At the AMQP protocol level, all receiving links that request a 'shared'
>> capability on the link and use the same link name (from the same topic
>> obviously) will share the subscription (i.e. the messages from that
>> subscription will be distributed between them). (This is not a standard
>> capability).
>>
>> I'm not sure if the JMS client will allow you to set the capabilities
>> though (Robbie?). At some point the JMS client will support JMS 2.0 which
>> includes the notion of shared subscriptions and as part of that a standard
>> approach at the protocol level will hopefully emerge.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Olivier Mallassi <ol...@gmail.com>.
- I am using session.createConsumer(myTopic, "messageSelector") so AFAIK,
it is not durable subscription. I was also reading
http://qpid.2158936.n2.nabble.com/Autodelete-queues-not-deleted-td7633221.html
and the QueuePolicy. Not sure how it maps to the jms destination name
(maybe the jms.queueprefix) but maybe that can help
- indeed JMS 2.0 defined shared subscription. Anyway, maybe during that
time I need to rely on AMQP 0.10 bindings (within the broker) to have
queues on which consumers can compete.
On Tue, Dec 22, 2015 at 10:39 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 12/22/2015 09:22 AM, Olivier Mallassi wrote:
>
>> by the way, wen I consume from a node that is a topic, the JMS / AMQP 1.0
>> creates a queue with an uniqueID for each receiver (e.g.
>>
>> MyComponent_qpid-jms:receiver:ID::3008640b-8ac6-4c87-9485-6156773c79b7:1:1:1:payments)
>>
>
> Actually that queue is created on the broker side. The name comes from the
> container id and link name.
>
> - is there a way to auto-delete this "queue" when the consumer JVM shut
>> down?
>>
>
> It should be auto-deleted by default, unless the client requests
> otherwise. Is it a durable subscription on the topic that you created?
>
> - is there a way to share this "queue" between multiple consumers so that
>> they can compete each other?
>>
>
> At the AMQP protocol level, all receiving links that request a 'shared'
> capability on the link and use the same link name (from the same topic
> obviously) will share the subscription (i.e. the messages from that
> subscription will be distributed between them). (This is not a standard
> capability).
>
> I'm not sure if the JMS client will allow you to set the capabilities
> though (Robbie?). At some point the JMS client will support JMS 2.0 which
> includes the notion of shared subscriptions and as part of that a standard
> approach at the protocol level will hopefully emerge.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Gordon Sim <gs...@redhat.com>.
On 12/22/2015 08:43 PM, Olivier Mallassi wrote:
> Looking at the qpid.filter definition, it looks like I can use a rich
> grammar (AND, OR, LIKE?). Is this define somewhere?
It is the JMS selector syntax, as defined in the JMS spec (3.8.1 in
https://docs.oracle.com/cd/E19957-01/816-5904-10/816-5904-10.pdf)
> Regarding the --argument, I was looking at the python source (
> https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/py/qpid-config)
> but cannot find anything.
Around line 246 (or so, depending on exact version):
> group3.add_option("--argument", dest="extra_arguments", action="append", default=[],
> metavar="<NAME=VALUE>", help="Specify a key-value pair to add to queue arguments")
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Olivier Mallassi <ol...@gmail.com>.
it looks like this is exactly what I was looking for! I will try it (after
christmas)
Looking at the qpid.filter definition, it looks like I can use a rich
grammar (AND, OR, LIKE?). Is this define somewhere?
Regarding the --argument, I was looking at the python source (
https://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/py/qpid-config)
but cannot find anything.
anyway. Thank you very much.
oliv/
On Tue, Dec 22, 2015 at 7:23 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 12/22/2015 06:13 PM, Gordon Sim wrote:
>
> (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).
>>
>
> And if you didn't want to do any selection at the exchange, and just rely
> on the selector, you could bind the queue to a 'fanout' exchange.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Olivier Mallassi <ol...@gmail.com>.
Gordon, thx. this just what I needed.
oliv/
On Tue, Dec 22, 2015 at 7:23 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 12/22/2015 06:13 PM, Gordon Sim wrote:
>
> (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).
>>
>
> And if you didn't want to do any selection at the exchange, and just rely
> on the selector, you could bind the queue to a 'fanout' exchange.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Gordon Sim <gs...@redhat.com>.
On 12/22/2015 06:13 PM, Gordon Sim wrote:
> (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).
And if you didn't want to do any selection at the exchange, and just
rely on the selector, you could bind the queue to a 'fanout' exchange.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Gordon Sim <gs...@redhat.com>.
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Olivier Mallassi <ol...@gmail.com>.
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.
On Tue, Dec 22, 2015 at 5:57 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 12/22/2015 04:09 PM, Olivier Mallassi wrote:
>
>> (my apologies for bothering you with all these questions...)
>>
>
> Not at all!
>
> It looks like JMSType (subject) or JMSCorrelationID are not used (or that
>> my binding is false).
>>
>
> The subject should match if you use that as the binding key when creating
> the binding (instead of ''). The headers exchange won't look at the
> correlation-id though I'm afraid.
>
> Is there a particular reason you need/want a headers exchange as opposed
> to just using a selector on a topic subscription (to e.g. a fanout
> exchange)?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Gordon Sim <gs...@redhat.com>.
On 12/22/2015 04:09 PM, Olivier Mallassi wrote:
> (my apologies for bothering you with all these questions...)
Not at all!
> It looks like JMSType (subject) or JMSCorrelationID are not used (or that
> my binding is false).
The subject should match if you use that as the binding key when
creating the binding (instead of ''). The headers exchange won't look at
the correlation-id though I'm afraid.
Is there a particular reason you need/want a headers exchange as opposed
to just using a selector on a topic subscription (to e.g. a fanout
exchange)?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Olivier Mallassi <ol...@gmail.com>.
(my apologies for bothering you with all these questions...)
let's say I am sending messages using the JMS / AMQP 1.0 client with JMS
properties set, e.g:
Message message = session.createTextMessage(".....");
message.setJMSType("mysubject"); //mapped to the amqp subject
https://issues.apache.org/jira/browse/QPID-6432
...
message.setJMSCorrelationID("abc");
message.setStringProperty("color", "blue");
message.setIntProperty("weight", 2600);
producer.send(message);
into a destination which is, in that case, *a header exchange* (but AMQP
1.0 does care about that).
on the broker side (cpp version), is there a way to subscribe to this
header exchange and use the JMS headers? (this is less rich than
JMSSelector but good enough)
./qpid-tools-0.32/build/scripts-2.7/qpid-config -b 192.168.56.102:12000 add
exchange headers subjects
./qpid-tools-0.32/build/scripts-2.7/qpid-config -b 192.168.56.102:10000 add
queue mysubscription
./qpid-tools-0.32/build/scripts-2.7/qpid-config -b 192.168.56.102:10000
bind subjects mysubscription '' any color='blue', amqp.correlation_id='abc'
It looks like JMSType (subject) or JMSCorrelationID are not used (or that
my binding is false).
Cheers.
On Tue, Dec 22, 2015 at 11:11 AM, Robbie Gemmell <ro...@gmail.com>
wrote:
> On 22 December 2015 at 09:39, Gordon Sim <gs...@redhat.com> wrote:
> > On 12/22/2015 09:22 AM, Olivier Mallassi wrote:
> >>
> >> by the way, wen I consume from a node that is a topic, the JMS / AMQP
> 1.0
> >> creates a queue with an uniqueID for each receiver (e.g.
> >>
> >>
> MyComponent_qpid-jms:receiver:ID::3008640b-8ac6-4c87-9485-6156773c79b7:1:1:1:payments)
> >
> >
> > Actually that queue is created on the broker side. The name comes from
> the
> > container id and link name.
> >
> >> - is there a way to auto-delete this "queue" when the consumer JVM shut
> >> down?
> >
> >
> > It should be auto-deleted by default, unless the client requests
> otherwise.
> > Is it a durable subscription on the topic that you created?
> >
> >> - is there a way to share this "queue" between multiple consumers so
> that
> >> they can compete each other?
> >
> >
> > At the AMQP protocol level, all receiving links that request a 'shared'
> > capability on the link and use the same link name (from the same topic
> > obviously) will share the subscription (i.e. the messages from that
> > subscription will be distributed between them). (This is not a standard
> > capability).
> >
> > I'm not sure if the JMS client will allow you to set the capabilities
> though
> > (Robbie?).
>
> Not at present no. Having some defined method/syntax for configuring
> lower level AMQP link/terminus details to other values within the JMS
> client is something thats been mentioned in passing in the AMQP
> BINDMAP TC, but we have yet to look into it further.
>
> > At some point the JMS client will support JMS 2.0 which includes
> > the notion of shared subscriptions and as part of that a standard
> approach
> > at the protocol level will hopefully emerge.
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Robbie Gemmell <ro...@gmail.com>.
On 22 December 2015 at 09:39, Gordon Sim <gs...@redhat.com> wrote:
> On 12/22/2015 09:22 AM, Olivier Mallassi wrote:
>>
>> by the way, wen I consume from a node that is a topic, the JMS / AMQP 1.0
>> creates a queue with an uniqueID for each receiver (e.g.
>>
>> MyComponent_qpid-jms:receiver:ID::3008640b-8ac6-4c87-9485-6156773c79b7:1:1:1:payments)
>
>
> Actually that queue is created on the broker side. The name comes from the
> container id and link name.
>
>> - is there a way to auto-delete this "queue" when the consumer JVM shut
>> down?
>
>
> It should be auto-deleted by default, unless the client requests otherwise.
> Is it a durable subscription on the topic that you created?
>
>> - is there a way to share this "queue" between multiple consumers so that
>> they can compete each other?
>
>
> At the AMQP protocol level, all receiving links that request a 'shared'
> capability on the link and use the same link name (from the same topic
> obviously) will share the subscription (i.e. the messages from that
> subscription will be distributed between them). (This is not a standard
> capability).
>
> I'm not sure if the JMS client will allow you to set the capabilities though
> (Robbie?).
Not at present no. Having some defined method/syntax for configuring
lower level AMQP link/terminus details to other values within the JMS
client is something thats been mentioned in passing in the AMQP
BINDMAP TC, but we have yet to look into it further.
> At some point the JMS client will support JMS 2.0 which includes
> the notion of shared subscriptions and as part of that a standard approach
> at the protocol level will hopefully emerge.
>
>
>
> ---------------------------------------------------------------------
> 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: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Gordon Sim <gs...@redhat.com>.
On 12/22/2015 09:22 AM, Olivier Mallassi wrote:
> by the way, wen I consume from a node that is a topic, the JMS / AMQP 1.0
> creates a queue with an uniqueID for each receiver (e.g.
> MyComponent_qpid-jms:receiver:ID::3008640b-8ac6-4c87-9485-6156773c79b7:1:1:1:payments)
Actually that queue is created on the broker side. The name comes from
the container id and link name.
> - is there a way to auto-delete this "queue" when the consumer JVM shut
> down?
It should be auto-deleted by default, unless the client requests
otherwise. Is it a durable subscription on the topic that you created?
> - is there a way to share this "queue" between multiple consumers so that
> they can compete each other?
At the AMQP protocol level, all receiving links that request a 'shared'
capability on the link and use the same link name (from the same topic
obviously) will share the subscription (i.e. the messages from that
subscription will be distributed between them). (This is not a standard
capability).
I'm not sure if the JMS client will allow you to set the capabilities
though (Robbie?). At some point the JMS client will support JMS 2.0
which includes the notion of shared subscriptions and as part of that a
standard approach at the protocol level will hopefully emerge.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Olivier Mallassi <ol...@gmail.com>.
by the way, wen I consume from a node that is a topic, the JMS / AMQP 1.0
creates a queue with an uniqueID for each receiver (e.g.
MyComponent_qpid-jms:receiver:ID::3008640b-8ac6-4c87-9485-6156773c79b7:1:1:1:payments)
- is there a way to auto-delete this "queue" when the consumer JVM shut
down?
- is there a way to share this "queue" between multiple consumers so that
they can compete each other?
Cheers.
On Mon, Dec 21, 2015 at 9:51 PM, Olivier Mallassi <
olivier.mallassi@gmail.com> wrote:
> thanks.
>
> On Mon, Dec 21, 2015 at 9:45 PM, Gordon Sim <gs...@redhat.com> wrote:
>
>> On 12/21/2015 08:43 PM, Olivier Mallassi wrote:
>>
>>> Are the filters executed on the broker?
>>>
>>
>> Yes
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Olivier Mallassi <ol...@gmail.com>.
thanks.
On Mon, Dec 21, 2015 at 9:45 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 12/21/2015 08:43 PM, Olivier Mallassi wrote:
>
>> Are the filters executed on the broker?
>>
>
> Yes
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Gordon Sim <gs...@redhat.com>.
On 12/21/2015 08:43 PM, Olivier Mallassi wrote:
> Are the filters executed on the broker?
Yes
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Olivier Mallassi <ol...@gmail.com>.
Looks like my understanding of addressing in AMQP 1.0 is not that
good...and that I am still struggling to forget the AMQP 0.10 concepts. But
your comment helped me.
In fact my address was specifying a queue. so the behavior is as expected.
Are the filters executed on the broker?
On Mon, Dec 21, 2015 at 6:19 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 12/21/2015 05:02 PM, Olivier Mallassi wrote:
>
>> Based on this discussion, the JMSCorrelation ID should be ok in the next
>> release: https://issues.apache.org/jira/browse/QPID-6714
>>
>
> Yes, that is correct.
>
> Why do messages stay in the queue server side? related to
>> https://issues.apache.org/jira/browse/QPID-5030?
>>
>
> What address are you consuming from when you specify the filter? In qpidd
> terms, if you specify the filter when the node is an exchange (or topic)
> then the selector should be applied to select which messages get enqueued.
> If the node is a queue however then the selector only controls the messages
> actually consumed from the queue.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [C++ Broker][JMSSelector][AMQP 1.0] problem with JMSCorrelationID
while using JMS Selector
Posted by Gordon Sim <gs...@redhat.com>.
On 12/21/2015 05:02 PM, Olivier Mallassi wrote:
> Based on this discussion, the JMSCorrelation ID should be ok in the next
> release: https://issues.apache.org/jira/browse/QPID-6714
Yes, that is correct.
> Why do messages stay in the queue server side? related to
> https://issues.apache.org/jira/browse/QPID-5030?
What address are you consuming from when you specify the filter? In
qpidd terms, if you specify the filter when the node is an exchange (or
topic) then the selector should be applied to select which messages get
enqueued. If the node is a queue however then the selector only controls
the messages actually consumed from the queue.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org