qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: usage of message selectors in C++ Qpid 0.28 client (amqp 1.0)
Date Mon, 02 Feb 2015 15:17:41 GMT
Hi Robbie,

Thanks a lot for raising the JIRAs.

Regards
Jakub

On Mon, Feb 2, 2015 at 4:17 PM, Jakub Scholz <jakub@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 <gsim@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
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message