You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by "Hamid.Shahid" <ha...@sungard.com> on 2015/01/28 17:24:36 UTC
usage of message selectors in C++ Qpid 0.28 client (amqp 1.0)
Hi,
Is there any equivalent of JMS 'messageSelector' in QPID 0.28 C++ client API
using AMQP 1.0 protocol?
For example in JMS we can create a message receiver like this;
consumer = session.createConsumer(consumerDestination, uniqueAppID)
I want to create a similar one in C++ and this is how I am trying it, but it
seems not work; Is this the right way to do it?
respAddress = "'ResQueue'; {link:
{selector:\"uniqueAppID='("+uniqueAppID+")'\"}}"
Receiver respReceiver = session.createReceiver(respAddress);
thanks & Regards,
Hamid
-----
Best Regards,
Hamid.
--
View this message in context: http://qpid.2158936.n2.nabble.com/usage-of-message-selectors-in-C-Qpid-0-28-client-amqp-1-0-tp7619011.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: usage of message selectors in C++ Qpid 0.28 client (amqp 1.0)
Posted by Robbie Gemmell <ro...@gmail.com>.
On 2 February 2015 at 14:46, Robbie Gemmell <ro...@gmail.com> wrote:
> On 2 February 2015 at 13:08, Gordon Sim <gs...@redhat.com> wrote:
>> On 01/30/2015 03:15 PM, Jakub Scholz wrote:
>>>
>>> So, I did some playing around. And it looks like the filter configured
>>> this
>>> way works fine with Qpid C++ broker, but doesn't really work with
>>> ActiveMQ.
>>> The filter seems to be present in the attach commands, but seems to be
>>> ignored by the broker.
>>>
>>> 2015-01-30 16:00:50 [Protocol] trace
>>> [19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 -> @attach(18)
>>> [name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
>>> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
>>> source=@source(40) [address="queue://responseQueue", durable=0, timeout=0,
>>> dynamic=false, filter={:selector=@77567109365764 "status='licha'"}],
>>> target=@target(41) [address="queue://responseQueue", durable=0, timeout=0,
>>> dynamic=false], initial-delivery-count=0]
>>> 2015-01-30 16:00:50 [Protocol] trace
>>> [19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 <- @attach(18)
>>> [name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
>>> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
>>> source=@source(40) [address="queue://responseQueue", durable=0,
>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>>> filter={:selector=@77567109365764 "status='licha'"}], target=@target(41)
>>> [address="queue://responseQueue"], incomplete-unsettled=false,
>>> initial-delivery-count=0]
>>>
>>> Anyone has an idea why it doesn't work? The Java client seems to work fine
>>> with the selector and ActiveMQ.
>>
>>
>> ActiveMQ looks only at the name of the filter, not the descriptor of the
>> value, and expects it to be 'jms-selector'.
>>
>> You can control that by being more explicit in the address, e.g.:
>>
>> my-queue; {link:{filter:{name:jms-selector,
>> descriptor:'apache.org:selector-filter:string', value:'uniqueAppId=7'}}}
>>
>> ActiveMQ should really look at the descriptor, but we could also change the
>> name/key the client uses by default since a compliant broker doesn't really
>> care what that is anyway.
>>
>>
>
> It is also sending the filter on the attach response even though it
> isnt using it (since it looks for it by key and didnt find it, it cant
> be using it), which should also be corrected.
Raised as https://issues.apache.org/jira/browse/AMQ-5559, I will aim
to take a look at it soon and get something in before the next release
(after 5.11, which is due to finish its vote tonight).
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: usage of message selectors in C++ Qpid 0.28 client (amqp 1.0)
Posted by Robbie Gemmell <ro...@gmail.com>.
On 2 February 2015 at 13:08, Gordon Sim <gs...@redhat.com> wrote:
> On 01/30/2015 03:15 PM, Jakub Scholz wrote:
>>
>> So, I did some playing around. And it looks like the filter configured
>> this
>> way works fine with Qpid C++ broker, but doesn't really work with
>> ActiveMQ.
>> The filter seems to be present in the attach commands, but seems to be
>> ignored by the broker.
>>
>> 2015-01-30 16:00:50 [Protocol] trace
>> [19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 -> @attach(18)
>> [name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
>> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
>> source=@source(40) [address="queue://responseQueue", durable=0, timeout=0,
>> dynamic=false, filter={:selector=@77567109365764 "status='licha'"}],
>> target=@target(41) [address="queue://responseQueue", durable=0, timeout=0,
>> dynamic=false], initial-delivery-count=0]
>> 2015-01-30 16:00:50 [Protocol] trace
>> [19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 <- @attach(18)
>> [name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
>> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
>> source=@source(40) [address="queue://responseQueue", durable=0,
>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>> filter={:selector=@77567109365764 "status='licha'"}], target=@target(41)
>> [address="queue://responseQueue"], incomplete-unsettled=false,
>> initial-delivery-count=0]
>>
>> Anyone has an idea why it doesn't work? The Java client seems to work fine
>> with the selector and ActiveMQ.
>
>
> ActiveMQ looks only at the name of the filter, not the descriptor of the
> value, and expects it to be 'jms-selector'.
>
> You can control that by being more explicit in the address, e.g.:
>
> my-queue; {link:{filter:{name:jms-selector,
> descriptor:'apache.org:selector-filter:string', value:'uniqueAppId=7'}}}
>
> ActiveMQ should really look at the descriptor, but we could also change the
> name/key the client uses by default since a compliant broker doesn't really
> care what that is anyway.
>
>
It is also sending the filter on the attach response even though it
isnt using it (since it looks for it by key and didnt find it, it cant
be using it), which should also be corrected.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: usage of message selectors in C++ Qpid 0.28 client (amqp 1.0)
Posted by "Hamid.Shahid" <ha...@sungard.com>.
Thank you everyone for your feedback.
-----
Best Regards,
Hamid.
--
View this message in context: http://qpid.2158936.n2.nabble.com/usage-of-message-selectors-in-C-Qpid-0-28-client-amqp-1-0-tp7619011p7619343.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: usage of message selectors in C++ Qpid 0.28 client (amqp 1.0)
Posted by Robbie Gemmell <ro...@gmail.com>.
On 2 February 2015 at 13:08, Gordon Sim <gs...@redhat.com> wrote:
> On 01/30/2015 03:15 PM, Jakub Scholz wrote:
>>
>> So, I did some playing around. And it looks like the filter configured
>> this
>> way works fine with Qpid C++ broker, but doesn't really work with
>> ActiveMQ.
>> The filter seems to be present in the attach commands, but seems to be
>> ignored by the broker.
>>
>> 2015-01-30 16:00:50 [Protocol] trace
>> [19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 -> @attach(18)
>> [name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
>> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
>> source=@source(40) [address="queue://responseQueue", durable=0, timeout=0,
>> dynamic=false, filter={:selector=@77567109365764 "status='licha'"}],
>> target=@target(41) [address="queue://responseQueue", durable=0, timeout=0,
>> dynamic=false], initial-delivery-count=0]
>> 2015-01-30 16:00:50 [Protocol] trace
>> [19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 <- @attach(18)
>> [name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
>> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
>> source=@source(40) [address="queue://responseQueue", durable=0,
>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>> filter={:selector=@77567109365764 "status='licha'"}], target=@target(41)
>> [address="queue://responseQueue"], incomplete-unsettled=false,
>> initial-delivery-count=0]
>>
>> Anyone has an idea why it doesn't work? The Java client seems to work fine
>> with the selector and ActiveMQ.
>
>
> ActiveMQ looks only at the name of the filter, not the descriptor of the
> value, and expects it to be 'jms-selector'.
>
> You can control that by being more explicit in the address, e.g.:
>
> my-queue; {link:{filter:{name:jms-selector,
> descriptor:'apache.org:selector-filter:string', value:'uniqueAppId=7'}}}
>
> ActiveMQ should really look at the descriptor,
Raised as https://issues.apache.org/jira/browse/AMQ-5560
> but we could also change the
> name/key the client uses by default since a compliant broker doesn't really
> care what that is anyway.
>
>
> ---------------------------------------------------------------------
> 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: usage of message selectors in C++ Qpid 0.28 client (amqp 1.0)
Posted by Robbie Gemmell <ro...@gmail.com>.
On 2 February 2015 at 14:43, Jakub Scholz <ja...@scholz.cz> wrote:
> Hi Gordon,
>
> Thanks for your help. The full filter specification indeed seems to work
> fine with ActiveMQ / A-MQ.
>
> -----
>
> Looking only at the filter name instead of the descriptor is one problem.
> Another problem is that if the broker doesn't understand the filter it
> should in my opinion not ignore it "silently". As I understood the specs,
> the A-MQ should not sent the attach command to the client with the filter
> if it didn't understood the filter, or?
Nice cross-post ;)
>
> That said, the Qpid broker seems to behave bit more in line with my
> expectations:
>
> 2015-02-02 15:23:37 [Protocol] trace
> [57379056-3e51-42ca-9908-e859f3b49be1]: 0 -> @attach(18)
> [name="responseQueue_b9d5e14f-ae4c-465c-85a8-36acab81fe6a", handle=0,
> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [address="responseQueue", durable=0, timeout=0, dynamic=false,
> filter={:"my-selector"=@:"apache.org:xxxselector-filter:string"
> "status='suda'"}], target=@target(41) [address="responseQueue", durable=0,
> timeout=0, dynamic=false], initial-delivery-count=0]
> 2015-02-02 15:23:37 [Protocol] trace
> [57379056-3e51-42ca-9908-e859f3b49be1]: 0 <- @attach(18)
> [name="responseQueue_b9d5e14f-ae4c-465c-85a8-36acab81fe6a", handle=0,
> role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [address="responseQueue", durable=0, timeout=0, dynamic=false],
> target=@target(41) [durable=0, timeout=0, dynamic=false],
> initial-delivery-count=0]
>
> It responds with an attach but without the filter - that is what I would
> expect based on the AMQP 1.0 spec. However, the Qpid Messaging client seems
> to ignore that. Is there some way how to find out that the receiver was
> created but without the filter? Shouldn't the client raise an error in such
> case?
>
> Thanks & Regards
> JAkub
>
> On Mon, Feb 2, 2015 at 2:08 PM, Gordon Sim <gs...@redhat.com> wrote:
>
>> On 01/30/2015 03:15 PM, Jakub Scholz wrote:
>>
>>> So, I did some playing around. And it looks like the filter configured
>>> this
>>> way works fine with Qpid C++ broker, but doesn't really work with
>>> ActiveMQ.
>>> The filter seems to be present in the attach commands, but seems to be
>>> ignored by the broker.
>>>
>>> 2015-01-30 16:00:50 [Protocol] trace
>>> [19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 -> @attach(18)
>>> [name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
>>> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
>>> source=@source(40) [address="queue://responseQueue", durable=0,
>>> timeout=0,
>>> dynamic=false, filter={:selector=@77567109365764 "status='licha'"}],
>>> target=@target(41) [address="queue://responseQueue", durable=0,
>>> timeout=0,
>>> dynamic=false], initial-delivery-count=0]
>>> 2015-01-30 16:00:50 [Protocol] trace
>>> [19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 <- @attach(18)
>>> [name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
>>> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
>>> source=@source(40) [address="queue://responseQueue", durable=0,
>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>>> filter={:selector=@77567109365764 "status='licha'"}], target=@target(41)
>>> [address="queue://responseQueue"], incomplete-unsettled=false,
>>> initial-delivery-count=0]
>>>
>>> Anyone has an idea why it doesn't work? The Java client seems to work fine
>>> with the selector and ActiveMQ.
>>>
>>
>> ActiveMQ looks only at the name of the filter, not the descriptor of the
>> value, and expects it to be 'jms-selector'.
>>
>> You can control that by being more explicit in the address, e.g.:
>>
>> my-queue; {link:{filter:{name:jms-selector, descriptor:'apache.org:
>> selector-filter:string', value:'uniqueAppId=7'}}}
>>
>> ActiveMQ should really look at the descriptor, but we could also change
>> the name/key the client uses by default since a compliant broker doesn't
>> really care what that is anyway.
>>
>>
>> ---------------------------------------------------------------------
>> 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: usage of message selectors in C++ Qpid 0.28 client (amqp 1.0)
Posted by Jakub Scholz <ja...@scholz.cz>.
Hi Robbie,
Thanks a lot for raising the JIRAs.
Regards
Jakub
On Mon, Feb 2, 2015 at 4:17 PM, Jakub Scholz <ja...@scholz.cz> wrote:
> Hi Gordon,
>
> Great, the assert raises the error, I completely forgot about it. At least
> on a first look, it seems to work fine and it does what I would expect.
>
> Thanks & Regards
> Jakub
>
> On Mon, Feb 2, 2015 at 4:03 PM, Gordon Sim <gs...@redhat.com> wrote:
>
>> On 02/02/2015 02:43 PM, Jakub Scholz wrote:
>>
>>> Looking only at the filter name instead of the descriptor is one problem.
>>> Another problem is that if the broker doesn't understand the filter it
>>> should in my opinion not ignore it "silently". As I understood the specs,
>>> the A-MQ should not sent the attach command to the client with the filter
>>> if it didn't understood the filter, or?
>>>
>>
>> Yes, you are correct.
>>
>> That said, the Qpid broker seems to behave bit more in line with my
>>> expectations:
>>>
>>> 2015-02-02 15:23:37 [Protocol] trace
>>> [57379056-3e51-42ca-9908-e859f3b49be1]: 0 -> @attach(18)
>>> [name="responseQueue_b9d5e14f-ae4c-465c-85a8-36acab81fe6a", handle=0,
>>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>>> [address="responseQueue", durable=0, timeout=0, dynamic=false,
>>> filter={:"my-selector"=@:"apache.org:xxxselector-filter:string"
>>> "status='suda'"}], target=@target(41) [address="responseQueue",
>>> durable=0,
>>> timeout=0, dynamic=false], initial-delivery-count=0]
>>> 2015-02-02 15:23:37 [Protocol] trace
>>> [57379056-3e51-42ca-9908-e859f3b49be1]: 0 <- @attach(18)
>>> [name="responseQueue_b9d5e14f-ae4c-465c-85a8-36acab81fe6a", handle=0,
>>> role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>>> [address="responseQueue", durable=0, timeout=0, dynamic=false],
>>> target=@target(41) [durable=0, timeout=0, dynamic=false],
>>> initial-delivery-count=0]
>>>
>>> It responds with an attach but without the filter - that is what I would
>>> expect based on the AMQP 1.0 spec. However, the Qpid Messaging client
>>> seems
>>> to ignore that. Is there some way how to find out that the receiver was
>>> created but without the filter?
>>>
>>
>> Yes, you can use 'assert:always' and that should check that all requested
>> filters, capabilities etc are reflected in the peers attach response.
>>
>> Shouldn't the client raise an error in such case?
>>>
>>
>> Over 0-10, differences in details such as specific queue properties,
>> weren't treated as an error unless the assert was specified. For 1.0 I went
>> with what seemed like a similar approach, and only verify details in the
>> attach requested versus the attach received from the peer if asserts are on.
>>
>> That may not be the best choice for things like filters.
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
Re: usage of message selectors in C++ Qpid 0.28 client (amqp 1.0)
Posted by Jakub Scholz <ja...@scholz.cz>.
Hi Gordon,
Great, the assert raises the error, I completely forgot about it. At least
on a first look, it seems to work fine and it does what I would expect.
Thanks & Regards
Jakub
On Mon, Feb 2, 2015 at 4:03 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 02/02/2015 02:43 PM, Jakub Scholz wrote:
>
>> Looking only at the filter name instead of the descriptor is one problem.
>> Another problem is that if the broker doesn't understand the filter it
>> should in my opinion not ignore it "silently". As I understood the specs,
>> the A-MQ should not sent the attach command to the client with the filter
>> if it didn't understood the filter, or?
>>
>
> Yes, you are correct.
>
> That said, the Qpid broker seems to behave bit more in line with my
>> expectations:
>>
>> 2015-02-02 15:23:37 [Protocol] trace
>> [57379056-3e51-42ca-9908-e859f3b49be1]: 0 -> @attach(18)
>> [name="responseQueue_b9d5e14f-ae4c-465c-85a8-36acab81fe6a", handle=0,
>> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>> [address="responseQueue", durable=0, timeout=0, dynamic=false,
>> filter={:"my-selector"=@:"apache.org:xxxselector-filter:string"
>> "status='suda'"}], target=@target(41) [address="responseQueue", durable=0,
>> timeout=0, dynamic=false], initial-delivery-count=0]
>> 2015-02-02 15:23:37 [Protocol] trace
>> [57379056-3e51-42ca-9908-e859f3b49be1]: 0 <- @attach(18)
>> [name="responseQueue_b9d5e14f-ae4c-465c-85a8-36acab81fe6a", handle=0,
>> role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
>> [address="responseQueue", durable=0, timeout=0, dynamic=false],
>> target=@target(41) [durable=0, timeout=0, dynamic=false],
>> initial-delivery-count=0]
>>
>> It responds with an attach but without the filter - that is what I would
>> expect based on the AMQP 1.0 spec. However, the Qpid Messaging client
>> seems
>> to ignore that. Is there some way how to find out that the receiver was
>> created but without the filter?
>>
>
> Yes, you can use 'assert:always' and that should check that all requested
> filters, capabilities etc are reflected in the peers attach response.
>
> Shouldn't the client raise an error in such case?
>>
>
> Over 0-10, differences in details such as specific queue properties,
> weren't treated as an error unless the assert was specified. For 1.0 I went
> with what seemed like a similar approach, and only verify details in the
> attach requested versus the attach received from the peer if asserts are on.
>
> That may not be the best choice for things like filters.
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: usage of message selectors in C++ Qpid 0.28 client (amqp 1.0)
Posted by Gordon Sim <gs...@redhat.com>.
On 02/02/2015 02:43 PM, Jakub Scholz wrote:
> Looking only at the filter name instead of the descriptor is one problem.
> Another problem is that if the broker doesn't understand the filter it
> should in my opinion not ignore it "silently". As I understood the specs,
> the A-MQ should not sent the attach command to the client with the filter
> if it didn't understood the filter, or?
Yes, you are correct.
> That said, the Qpid broker seems to behave bit more in line with my
> expectations:
>
> 2015-02-02 15:23:37 [Protocol] trace
> [57379056-3e51-42ca-9908-e859f3b49be1]: 0 -> @attach(18)
> [name="responseQueue_b9d5e14f-ae4c-465c-85a8-36acab81fe6a", handle=0,
> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [address="responseQueue", durable=0, timeout=0, dynamic=false,
> filter={:"my-selector"=@:"apache.org:xxxselector-filter:string"
> "status='suda'"}], target=@target(41) [address="responseQueue", durable=0,
> timeout=0, dynamic=false], initial-delivery-count=0]
> 2015-02-02 15:23:37 [Protocol] trace
> [57379056-3e51-42ca-9908-e859f3b49be1]: 0 <- @attach(18)
> [name="responseQueue_b9d5e14f-ae4c-465c-85a8-36acab81fe6a", handle=0,
> role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [address="responseQueue", durable=0, timeout=0, dynamic=false],
> target=@target(41) [durable=0, timeout=0, dynamic=false],
> initial-delivery-count=0]
>
> It responds with an attach but without the filter - that is what I would
> expect based on the AMQP 1.0 spec. However, the Qpid Messaging client seems
> to ignore that. Is there some way how to find out that the receiver was
> created but without the filter?
Yes, you can use 'assert:always' and that should check that all
requested filters, capabilities etc are reflected in the peers attach
response.
> Shouldn't the client raise an error in such case?
Over 0-10, differences in details such as specific queue properties,
weren't treated as an error unless the assert was specified. For 1.0 I
went with what seemed like a similar approach, and only verify details
in the attach requested versus the attach received from the peer if
asserts are on.
That may not be the best choice for things like filters.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: usage of message selectors in C++ Qpid 0.28 client (amqp 1.0)
Posted by Jakub Scholz <ja...@scholz.cz>.
Hi Gordon,
Thanks for your help. The full filter specification indeed seems to work
fine with ActiveMQ / A-MQ.
-----
Looking only at the filter name instead of the descriptor is one problem.
Another problem is that if the broker doesn't understand the filter it
should in my opinion not ignore it "silently". As I understood the specs,
the A-MQ should not sent the attach command to the client with the filter
if it didn't understood the filter, or?
That said, the Qpid broker seems to behave bit more in line with my
expectations:
2015-02-02 15:23:37 [Protocol] trace
[57379056-3e51-42ca-9908-e859f3b49be1]: 0 -> @attach(18)
[name="responseQueue_b9d5e14f-ae4c-465c-85a8-36acab81fe6a", handle=0,
role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
[address="responseQueue", durable=0, timeout=0, dynamic=false,
filter={:"my-selector"=@:"apache.org:xxxselector-filter:string"
"status='suda'"}], target=@target(41) [address="responseQueue", durable=0,
timeout=0, dynamic=false], initial-delivery-count=0]
2015-02-02 15:23:37 [Protocol] trace
[57379056-3e51-42ca-9908-e859f3b49be1]: 0 <- @attach(18)
[name="responseQueue_b9d5e14f-ae4c-465c-85a8-36acab81fe6a", handle=0,
role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
[address="responseQueue", durable=0, timeout=0, dynamic=false],
target=@target(41) [durable=0, timeout=0, dynamic=false],
initial-delivery-count=0]
It responds with an attach but without the filter - that is what I would
expect based on the AMQP 1.0 spec. However, the Qpid Messaging client seems
to ignore that. Is there some way how to find out that the receiver was
created but without the filter? Shouldn't the client raise an error in such
case?
Thanks & Regards
JAkub
On Mon, Feb 2, 2015 at 2:08 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 01/30/2015 03:15 PM, Jakub Scholz wrote:
>
>> So, I did some playing around. And it looks like the filter configured
>> this
>> way works fine with Qpid C++ broker, but doesn't really work with
>> ActiveMQ.
>> The filter seems to be present in the attach commands, but seems to be
>> ignored by the broker.
>>
>> 2015-01-30 16:00:50 [Protocol] trace
>> [19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 -> @attach(18)
>> [name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
>> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
>> source=@source(40) [address="queue://responseQueue", durable=0,
>> timeout=0,
>> dynamic=false, filter={:selector=@77567109365764 "status='licha'"}],
>> target=@target(41) [address="queue://responseQueue", durable=0,
>> timeout=0,
>> dynamic=false], initial-delivery-count=0]
>> 2015-01-30 16:00:50 [Protocol] trace
>> [19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 <- @attach(18)
>> [name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
>> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
>> source=@source(40) [address="queue://responseQueue", durable=0,
>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>> filter={:selector=@77567109365764 "status='licha'"}], target=@target(41)
>> [address="queue://responseQueue"], incomplete-unsettled=false,
>> initial-delivery-count=0]
>>
>> Anyone has an idea why it doesn't work? The Java client seems to work fine
>> with the selector and ActiveMQ.
>>
>
> ActiveMQ looks only at the name of the filter, not the descriptor of the
> value, and expects it to be 'jms-selector'.
>
> You can control that by being more explicit in the address, e.g.:
>
> my-queue; {link:{filter:{name:jms-selector, descriptor:'apache.org:
> selector-filter:string', value:'uniqueAppId=7'}}}
>
> ActiveMQ should really look at the descriptor, but we could also change
> the name/key the client uses by default since a compliant broker doesn't
> really care what that is anyway.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: usage of message selectors in C++ Qpid 0.28 client (amqp 1.0)
Posted by Gordon Sim <gs...@redhat.com>.
On 01/30/2015 03:15 PM, Jakub Scholz wrote:
> So, I did some playing around. And it looks like the filter configured this
> way works fine with Qpid C++ broker, but doesn't really work with ActiveMQ.
> The filter seems to be present in the attach commands, but seems to be
> ignored by the broker.
>
> 2015-01-30 16:00:50 [Protocol] trace
> [19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 -> @attach(18)
> [name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [address="queue://responseQueue", durable=0, timeout=0,
> dynamic=false, filter={:selector=@77567109365764 "status='licha'"}],
> target=@target(41) [address="queue://responseQueue", durable=0, timeout=0,
> dynamic=false], initial-delivery-count=0]
> 2015-01-30 16:00:50 [Protocol] trace
> [19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 <- @attach(18)
> [name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
> source=@source(40) [address="queue://responseQueue", durable=0,
> expiry-policy=:"session-end", timeout=0, dynamic=false,
> filter={:selector=@77567109365764 "status='licha'"}], target=@target(41)
> [address="queue://responseQueue"], incomplete-unsettled=false,
> initial-delivery-count=0]
>
> Anyone has an idea why it doesn't work? The Java client seems to work fine
> with the selector and ActiveMQ.
ActiveMQ looks only at the name of the filter, not the descriptor of the
value, and expects it to be 'jms-selector'.
You can control that by being more explicit in the address, e.g.:
my-queue; {link:{filter:{name:jms-selector,
descriptor:'apache.org:selector-filter:string', value:'uniqueAppId=7'}}}
ActiveMQ should really look at the descriptor, but we could also change
the name/key the client uses by default since a compliant broker doesn't
really care what that is anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: usage of message selectors in C++ Qpid 0.28 client (amqp 1.0)
Posted by Jakub Scholz <ja...@scholz.cz>.
So, I did some playing around. And it looks like the filter configured this
way works fine with Qpid C++ broker, but doesn't really work with ActiveMQ.
The filter seems to be present in the attach commands, but seems to be
ignored by the broker.
2015-01-30 16:00:50 [Protocol] trace
[19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 -> @attach(18)
[name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [address="queue://responseQueue", durable=0, timeout=0,
dynamic=false, filter={:selector=@77567109365764 "status='licha'"}],
target=@target(41) [address="queue://responseQueue", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
2015-01-30 16:00:50 [Protocol] trace
[19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 <- @attach(18)
[name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
source=@source(40) [address="queue://responseQueue", durable=0,
expiry-policy=:"session-end", timeout=0, dynamic=false,
filter={:selector=@77567109365764 "status='licha'"}], target=@target(41)
[address="queue://responseQueue"], incomplete-unsettled=false,
initial-delivery-count=0]
Anyone has an idea why it doesn't work? The Java client seems to work fine
with the selector and ActiveMQ.
Regards
Jakub
On Wed, Jan 28, 2015 at 5:41 PM, Jakub Scholz <ja...@scholz.cz> wrote:
> Hi Hamid,
>
> Have you tried it without the brackets? E.g.
> respAddress = "'ResQueue; {link:{selector:\"uniqueAppID='"+
> uniqueAppID+"'\"}}"
>
> That is the way how the selectors for custom properties worked for me when
> I was playing with them.
>
> Regards
> Jakub
>
> On Wed, Jan 28, 2015 at 5:24 PM, Hamid.Shahid <ha...@sungard.com>
> wrote:
>
>> (
>
>
>
>
Re: usage of message selectors in C++ Qpid 0.28 client (amqp 1.0)
Posted by Jakub Scholz <ja...@scholz.cz>.
Hi Hamid,
Have you tried it without the brackets? E.g.
respAddress = "'ResQueue; {link:{selector:\"uniqueAppID='"+
uniqueAppID+"'\"}}"
That is the way how the selectors for custom properties worked for me when
I was playing with them.
Regards
Jakub
On Wed, Jan 28, 2015 at 5:24 PM, Hamid.Shahid <ha...@sungard.com>
wrote:
> (