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:12 GMT
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