CODEWITHSUNDEEP
propertiesjmsactivemq-classic
Kilter444
Kilter444

Reputation: 31

jms message selectors

I am using ActiveMQ 5.5 and JMS. I have created a topic consumer with a message selector of 

key<>'aValue'

meaning that the consumer will only receive messages that have a property called "key" that does not have the value 'aValue'.

Then I send a message with no property called "key" (Note that the case is NOT that there is a property with a null value, there is no property.)

What puzzles me is that the message is delivered.

This is not the case if I use the operator NOT LIKE: 

key NOT LIKE 'aVal%'.

In this case the consumer does not receive the message. This is inconsistent in my mind.

This is what the JMS spec says:

A message selector matches a message when the selector evaluates to true when the message's header field and property values are substituted for their corresponding identifiers in the selector.

According to the SQL92 spec (which JMS message selectors syntax is based on) comparing anything to NULL results in NULL rather than to a value (TRUE or FALSE in this case). If this is the case the first case should not result in the message being received.

Has anybody come across this? Which result, the <> case or the NOT LIKE case, is the correct one when the producer has not specified the property and the consumer has a selector? Any ideas how this can be worked around?

Upvotes: 3

Views: 3855

Answers (1)

Biju Kunjummen
Biju Kunjummen

Reputation: 49915

Based on my limited reading, my understanding is this, first from the JMS spec:

If a property that does not exist in a message is referenced, its value is NULL.

So in your case the key identifier when substituted for property values will evaluate to NULL

The first expression will essentially be NULL<>'aValue', which is true in my mind

The second expression will be NULL NOT LIKE '%aVal' which the spec says will have an unknown outcome and ActiveMQ seems to have gone with true as the outcome:

If identifier of a LIKE or NOT LIKE operation is NULL, the value of the operation is unknown.

I think the fix will be to make the selector very explicit:

(key NOT NULL) AND ...

Upvotes: 3

Related Questions