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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
