Okay, now that I retested it, clearly I was wrong about the difference between a message with no properties and a message with different properties. They both behave the same. So based on what you say, I assume that it is correct for `NOT(null)` to yield `false` instead of `true`.
Jan -----Original Message----- From: Justin Bertram <jbert...@apache.org> Sent: středa 11. září 2024 16:09 To: users@activemq.apache.org Subject: Re: Filtering messages with no properties/headers in Artemis > ...my main concern has been the difference between a message that has properties which don't match and a message that does not have any properties at all. That main thing to keep in mind here is that these two cases are treated independently. The lack of a property is checked using "is NULL". Matching a property is done with comparison operators (i.e. =, >, >=, <, <=, <>). Justin On Wed, Sep 11, 2024 at 8:13 AM Jan Šmucr <jan.sm...@aimtecglobal.com> wrote: > I'll check one more time tomorrow (I'm on the phone now) but my main > concern has been the difference between a message that has properties > which don't match and a message that does not have any properties at all. > > Jan > > > ________________________________ > From: Justin Bertram <jbert...@apache.org> > Sent: Wednesday, September 11, 2024 3:04:42 PM > To: users@activemq.apache.org <users@activemq.apache.org> > Subject: Re: Filtering messages with no properties/headers in Artemis > > 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Facti > vemq.apache.org%2Fcomponents%2Fartemis%2Fdocumentation%2Flatest%2Ffilt > er-expressions.html%23filter-expressions&data=05%7C02%7CJan.Smucr%40ai > mtecglobal.com%7Cd2697f4d925d48c2f90708dcd26b64d0%7Cb3811028ce6e4b01bc > b0db419328ffc5%7C1%7C0%7C638616605957428967%7CUnknown%7CTWFpbGZsb3d8ey > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7 > C%7C%7C&sdata=VkeKlhyS5rb23QWaUgxMJAxraR2X6BDmRO7lEcacEFE%3D&reserved= > 0 > < > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Facti > vemq.apache.org%2Fcomponents%2Fartemis%2Fdocumentation%2Flatest%2Ffilt > er-expressions.html%23filter-expressions&data=05%7C02%7CJan.Smucr%40ai > mtecglobal.com%7Cd2697f4d925d48c2f90708dcd26b64d0%7Cb3811028ce6e4b01bc > b0db419328ffc5%7C1%7C0%7C638616605957437472%7CUnknown%7CTWFpbGZsb3d8ey > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7 > C%7C%7C&sdata=GzzAc%2BzEfS1wy9ZJ8UcjbsrfdRTkHJ9ej8wrxqCqFyE%3D&reserve > d=0 > > > [2] > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > .oracle.com%2Fjavaee%2F7%2Fapi%2Fjavax%2Fjms%2FMessage.html&data=05%7C > 02%7CJan.Smucr%40aimtecglobal.com%7Cd2697f4d925d48c2f90708dcd26b64d0%7 > Cb3811028ce6e4b01bcb0db419328ffc5%7C1%7C0%7C638616605957444096%7CUnkno > wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL > CJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=fkc9u1dUQ8jIcZ9yDrpRSfkpq4lkHiqw%2F9F > xhjdAldA%3D&reserved=0 > <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc > s.oracle.com%2Fjavaee%2F7%2Fapi%2Fjavax%2Fjms%2FMessage.html&data=05%7 > C02%7CJan.Smucr%40aimtecglobal.com%7Cd2697f4d925d48c2f90708dcd26b64d0% > 7Cb3811028ce6e4b01bcb0db419328ffc5%7C1%7C0%7C638616605957448249%7CUnkn > own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi > LCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=yaDc2vjU3BcI2xTPZFC0qForzelmQBIzJdVe > 2%2B4fitQ%3D&reserved=0> > > > > On Wed, Sep 11, 2024 at 3:46 AM Jan Šmucr <jan.sm...@aimtecglobal.com> > 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 > > >
