Hi Robbie, Thanks a lot for raising the JIRAs.
Regards Jakub On Mon, Feb 2, 2015 at 4:17 PM, Jakub Scholz <[email protected]> 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 <[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] >> >> >
