I raised QPID-8113 for this issue and pushed a simple fix.
I'll raise a separate JIRA covering the fact that the error handling here
is poor, an unknown filter should really cause an attach{source: null},
followed by an immediate detach rather than closing the connection - and
certainly not a decode error.
-- Rob
On 28 February 2018 at 14:41, Gordon Sim <g...@redhat.com> wrote:
> On 28/02/18 13:20, Rob Godfrey wrote:
>
>> I would assume this is not a new error
>>
>
> Agreed, was noting in passing.
>
> ... from the looks of things this is
>> the Broker not supporting the "apache.org:selector-filter:string" filter
>> type, and choking on the fact in a less than graceful way.
>> Looking at the Broker-J code in
>> org.apache.qpid.server.protocol.v1_0.type.messaging.codec.JM
>> SSelectorFilterConstructor
>> it appears that the symbolic descriptor is not defined correctly there
>> while the ulong descriptor is correct (which is why, for instance, the JMS
>> client works).
>>
>
> Yes, a javascript example I ran also used numeric and passed.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
