NullPointerException for Message filter with operators

[lebon]

When a filter is created with an operator  ( ie >=,  LIKE) HornetQ write a WARN message is logged when the property does not exists in a message.

So the query is very slow:

java.lang.NullPointerException
2010-11-08 14:59:44,375 WARN  [org.hornetq.core.filter.impl.FilterImpl] (Thread-25 (group:HornetQ-server-threads14230532-808321)) Invalid filter string: displayUserName LIKE 'Leb%'

OR

2010-11-08 14:27:45,578 WARN  [org.hornetq.core.filter.impl.FilterImpl] (Thread-14 (group:HornetQ-server-threads14230532-808321)) Invalid filter string: assignedDate>= 1249042739000
java.lang.NullPointerException
       at org.hornetq.core.filter.impl.FilterImpl.match(FilterImpl.java:160)
       at org.hornetq.core.server.impl.ServerConsumerImpl.handle(ServerConsumerImpl.java:207)
       at org.hornetq.core.server.impl.ServerConsumerImpl$BrowserDeliverer.run(ServerConsumerImpl.java:889)
       at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100)
       at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
       at java.util.concurrent.ThreadPoolExecut

[clebert.suconic]

So, the issue is with inexistent properties only? (Just trying to understand what's the issue you're reporting)

Right now the title is very vague (on he JIRA). if that's the issue I will rename it to "NullPointerException with inexistent properties"

[robertjlee]

We've just hit the same problem.

In our case, we have a message selector clause that refers to a property (a message header) that may not exist in any given message. If it does not exist, the message selector should return null and so the message should not be matched (according to our understanding of JMS message selectors). This is used in an OR clause with other clauses, and there may be multiple queues on the address where some will match and some won't.

This has resulted in gigabytes of logging, and errors due to out of disk space. Also, it may be inaccurate as it says that the message selector is invalid (which we don't believe is the case), and it isn't clear from the logs if the message was being dropped.

Looking at the SVN history for Operator.java we can see that there was a change made by jmesnil in March 2010 (version 8913) which replaced a Boolean.FALSE with a null.  The calling method casts the result to a Boolean but it in turn uses auto-boxing to change this into a boolean primitive which is now throwing a NPE.  This is then caught and a false is returned.  We are unable to find anything in Jira to help explain the change that was made so we are somewhat confused.  Was the intent to use Exception handling in this way or is this a hiccup due to auto-boxing?

It would seem like filters of the kind "(false or null) is null" would be unlikely to work correctly.

We have attached a unit test to HORNETQ-563 which we believe shows this problem.

[steven.hulshof]

We hit the same problem as described by Robert Lee in version 2.2.18.

This null value which is being returned is causing the same nullpointerexception.

What makes this very confusing, is that it matters which operator you use. The behaviour of HornetQ is inconsistent.

If one uses a 'IN' selector, it is fine to filter on non existing properties. The FilterImpl.match returns false in that case, which is okay. However if you use a 'NOT IN' selector and you filter on that same non-existing property, a null pointer exception is thrown.

Is it very hard to revert that change from jmesnil and return false instead of the null? It would make the logs more readable.