2012-09-15 164 views
2

我正在使用ActiveMQ 5.5和JMS。我創建了一個話題消費者與jms消息選擇器

key<>'aValue' 

消息選擇這意味着消費者將收到的只是一個所謂的「關鍵」不具有值'安勤物業的消息。

然後我送,沒有財產被稱爲「鑰匙」的消息(請注意,這種情況是不存在與空值的屬性,也沒有財產。)

令我百思不解的是,消息交付。

這是不是這樣的,如果我使用運算符NOT LIKE:

key NOT LIKE 'aVal%'. 

在這種情況下,消費者沒有收到消息。這在我看來是不一致的。

這就是JMS規範說:

消息選擇相匹配的消息時,在消息的頭字段和屬性值代替了選擇其相應的標識符選擇計算結果爲true。

根據SQL92規範(哪些JMS消息選擇器語法基於)將NULL與NULL進行比較會導致NULL,而不是返回值(在本例中爲TRUE或FALSE)。如果是這種情況,則第一種情況不應導致消息被接收。

有人遇到過嗎?當生產者沒有指定屬性並且消費者具有選擇器時,哪個結果是<> case還是NOT LIKE情況是正確的?任何想法如何解決這個問題?

回答

2

根據我有限的閱讀,我的理解是這樣的,首先從JMS規範:

如果沒有在郵件中存在的屬性被引用,其 值爲NULL。

所以你的情況取代時的屬性值將計算爲NULL的關鍵標識

第一個表達式將主要爲NULL <>「安勤」,這是真正的在我的腦海

的第二個表達式將NULL NOT LIKE「%AVAL」該規範說將有一個未知的結果和ActiveMQ的似乎與真正的消失作爲結局:

如果LIKE或NOT LIK的標識符E操作爲NULL,值爲 的操作未知。

我想修補程序將做出選擇很明確:

(key NOT NULL) AND ... 
+1

感謝您的回答。我會和其他JMS經紀人一起測試這個以確定解釋是否存在差異。您建議的解決方法不適用於ActiveMQ。它引發一個異常。我會在這裏添加它,當我得到片刻 – Kilter444