2011-10-02 53 views
4

使用JMS & WebSphere MQ,如果我使用消息選擇器來選擇性地出隊,並且有幾條消息具有相同的選擇標準,那麼我是否確保將匹配的第一條消息出列?是否有選擇性地出隊消息保持FIFO先進先出(MQ)?

例如給定隊列的消息

  1. {color: pink, name: alice}
  2. {color: blue, name: bob}
  3. {color: red, name: charlie}
  4. {color: blue, name: doug}

,如果我出列與選擇color='blue',我保證出列{color: blue, name: bob}?或者是否有機會獲得{color: blue, name: doug}而不是,即使它進一步進入隊列深度?

回答

3

請參閱不同WMQ連接工廠實現的RESCANINT屬性。從手動:

當在點對點域信息消費者使用消息 選擇器選擇它想要接收哪些消息時,WebSphere MQ JMS客戶端搜索WebSphere MQ隊列爲合適的報文在 隊列中由MsgDeliverySequence屬性確定的序列。當客戶端找到合適的消息並將其傳送給消費者時,客戶端將從隊列中的當前位置繼續搜索下一個合適的消息 。客戶端繼續以這種方式搜索 隊列,直到它到達隊列的末尾,或者直到 由該屬性的值 確定的時間間隔(以毫秒爲單位)已過期。在每種情況下,客戶端返回隊列開始的 以繼續其搜索,並且開始新的時間間隔 。

這個想法是,在一個非常繁忙的優先傳遞隊列中,一些優先級較高的消息可能會出現在隊列中,然後是選擇器的當前位置。從理論上講,應該首先消費更高優先級的消息,但消費者不會看到它,除非它從隊列頭開始尋找。當遊標到達結束點或達到RESCANINT時,遊標將重置爲隊列頭部。 RESCANINT的設置允許調整您希望選擇器如何響應以找到這些更高優先級的消息。

RESCANINT不針對FIFO交付。可能發生這種情況的另一種情況是,如果有多個線程重疊選擇標準。在這種情況下,一個線程可以鎖定一條消息,然後釋放它。雖然消息可能符合第二個線程,但如果該線程已經在隊列中傳遞了該位置,那麼它會觸及隊列的末尾或RESCANINT消逝以重新啓動光標以查找消息。

重新掃描間隔是在〜5000的任何正整數值被接受毫秒和默認值,雖然太低的值將導致抖動作爲光標連續地重置任何消息可以被消費之前。

作爲一個實際問題,您將收到的消息,以便如果隊列是FIFO,你必須對隊列該消息符合條件,不管什麼RESCANINT設置爲只有一個讀者。如果消息順序是必須嚴格保持,有如Sequential retrieval of messages描述的一些額外的考慮。這些歸結爲考慮通道,同步點等

+0

+1當具有從生產者到消費者只有一條路徑信息,多麼複雜的答案。考慮到被問到的簡單情況(所有信息具有相同的優先級和一個閱讀器),答案是「是的,這是FIFO順序」,對吧? – MaDa

+2

OP沒有提到多少線程,是否有網絡轉發或可能弄亂順序,所以我想我會提供有關內部和依賴一點點信息的任何其他問題。此外,涉及的問題在異步消息傳遞中固有,但不同的提供商以稍微不同的方式解決它們。所以即使答案的本質是「是的,它就是先進先出」,重要的是要知道它是可調的,以及這可能會如何影響答案。 –

+0

這是一個很好的答案。謝謝T.Rob – Synesso

2

請參閱「The order in which messages are retrieved from a queue」一章和以下內容:「Getting a particular message」。

總結:獲取消息忽略FIFO順序的唯一方法是通過其消息ID或相關ID獲取特定消息。一個隊列也可以配置爲以FIFO +優先級順序交付,但這不是您考慮的選項。最後,如果消息被分組,消息順序會變得複雜,但是,這不是你的情況。