qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: usage of message selectors in C++ Qpid 0.28 client (amqp 1.0)
Date Mon, 02 Feb 2015 15:03:03 GMT
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 

> 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

View raw message