On 2 February 2015 at 14:43, Jakub Scholz <[email protected]> wrote:
> Hi Gordon,
>
> Thanks for your help. The full filter specification indeed seems to work
> fine with ActiveMQ / A-MQ.
>
> -----
>
> 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?
Nice cross-post ;)
>
> 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? Shouldn't the client raise an error in such
> case?
>
> Thanks & Regards
> JAkub
>
> On Mon, Feb 2, 2015 at 2:08 PM, Gordon Sim <[email protected]> wrote:
>
>> On 01/30/2015 03:15 PM, Jakub Scholz wrote:
>>
>>> So, I did some playing around. And it looks like the filter configured
>>> this
>>> way works fine with Qpid C++ broker, but doesn't really work with
>>> ActiveMQ.
>>> The filter seems to be present in the attach commands, but seems to be
>>> ignored by the broker.
>>>
>>> 2015-01-30 16:00:50 [Protocol] trace
>>> [19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 -> @attach(18)
>>> [name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
>>> handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0,
>>> source=@source(40) [address="queue://responseQueue", durable=0,
>>> timeout=0,
>>> dynamic=false, filter={:selector=@77567109365764 "status='licha'"}],
>>> target=@target(41) [address="queue://responseQueue", durable=0,
>>> timeout=0,
>>> dynamic=false], initial-delivery-count=0]
>>> 2015-01-30 16:00:50 [Protocol] trace
>>> [19d9dcef-2e7c-4738-b549-e8a3c5737c22]: 0 <- @attach(18)
>>> [name="queue://responseQueue_0dd729c8-6782-4380-affb-05ce401a75d3",
>>> handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0,
>>> source=@source(40) [address="queue://responseQueue", durable=0,
>>> expiry-policy=:"session-end", timeout=0, dynamic=false,
>>> filter={:selector=@77567109365764 "status='licha'"}], target=@target(41)
>>> [address="queue://responseQueue"], incomplete-unsettled=false,
>>> initial-delivery-count=0]
>>>
>>> Anyone has an idea why it doesn't work? The Java client seems to work fine
>>> with the selector and ActiveMQ.
>>>
>>
>> ActiveMQ looks only at the name of the filter, not the descriptor of the
>> value, and expects it to be 'jms-selector'.
>>
>> You can control that by being more explicit in the address, e.g.:
>>
>> my-queue; {link:{filter:{name:jms-selector, descriptor:'apache.org:
>> selector-filter:string', value:'uniqueAppId=7'}}}
>>
>> ActiveMQ should really look at the descriptor, but we could also change
>> the name/key the client uses by default since a compliant broker doesn't
>> really care what that is anyway.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
