The filtering is essentially the SQL92 subset JMS / Jakarta Messaging outlines: https://jakarta.ee/specifications/messaging/3.1/apidocs/jakarta.messaging/jakarta/jms/message
It notes that "a selector that evaluates to false or unknown does not match". It says for properties that "If a property that does not exist in a message is referenced, its value is NULL". It also later notes that for a comparison operator like = or <>, "If either of the type values evaluates to NULL, the value of the expression is unknown." NOT <unknown>, is also an unknown as per the table in 'The definition of the NOT operator' in the section about NULL, and therefore doesnt match. So if you want to specifically test for property not-present / null or vice versa, you should use "<property> IS NULL" or "<property> IS NOT NULL" to ensure that result of that check is true or false rather than unknown, and that any later NOT of your overall result is also a boolean rather than unknown. On Thu, 12 Sept 2024 at 06:38, Jan Šmucr <jan.sm...@aimtecglobal.com> wrote: > > 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 > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org For additional commands, e-mail: users-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
