What you're seeing is, in fact, the expected behavior. As noted in the
documentation [1] the ActiveMQ Artemis filter syntax is based on the same
subset of the SQL 92 syntax as JMS/Jakarta selectors and that documentation
[2] states:
If a property that does not exist in a message is referenced, its value
is NULL.
...
identifier IS NULL (comparison operator that tests for a null header
field value or a missing property value)
Therefore, if you want a queue to catch the messages that q1 and q2 miss
you'd need something like this:
* addr1
* q1 [key = 'value']
* q2 [NOT (key = 'value')]
* q3 [key is NULL]
I can't find the reference(s) at the moment, but I'm fairly certain we've
covered this on the mailing list before.
Justin
[1]
https://activemq.apache.org/components/artemis/documentation/latest/filter-expressions.html#filter-expressions
[2] https://docs.oracle.com/javaee/7/api/javax/jms/Message.html
On Wed, Sep 11, 2024 at 3:46 AM Jan Šmucr <[email protected]>
wrote:
> Hello.
> I've hit an odd behavior in Artemis (tested with 2.32 and 2.37), and I'd
> like to know if it's a bug or a feature.
> Say I have an anycast address `addr1` and two queues: `q1` and `q2`. Both
> queues have a filter on them, and the `q2`'s filter is a negation of the
> `q1`'s filter. Schematically:
>
> * addr1
> * q1 [key = 'value']
> * q2 [NOT (key = 'value')]
> Intuitively, whatever message does not fulfill the first condition (either
> there's no `key` property, or its value is different) should be routed to
> `q2`. And that works but only as long as the message has at least some
> properties.
> In other words:
>
> * A message with property `key` of value `value` ends up in the `q1`
> queue.
> * A message with property `key` of value `foobar` ends up in the `q2`
> queue.
> * A message with property `foo` of value `bar` ends up in the `q2`
> queue.
> * And finally, a message with no properties is lost.
> Is it really supposed to work like this?
> Thanks.
> Jan
>
