2013-04-17 32 views
3

我正在與嘗試使用IBM Websphere MQ中的JMS隊列實現負載平衡行爲的人一起工作。因此,他們將多個Camel JMS使用者配置爲從同一個隊列讀取數據。儘管根據JMS規範(我上次無論如何看)這種行爲是未定義的,但他們期望一種循環/負載平衡行爲。而且,雖然規範沒有定義,但我認爲Websphere MQ的正常行爲是僅向其中一個消費者傳遞消息,並且它可能會執行某種類型的負載平衡。請看這裏,例如:When multi MessageConsumer connect to same queue(Websphere MQ),how to load balance message-consumer?同一Websphere MQ JMS隊列上的兩個消費者都收到相同的消息

但是在這種特殊情況下,看起來都是消費者正在接收相同的消息。

任何更擅長Websphere MQ的人都會對此有所瞭解嗎?有什麼情況會出現這種行爲?是否有任何配置更改可以緩解此問題?

我傾向於告訴每個人在這裏使用本地Websphere MQ集羣設施,並避免讓多個消費者指向相同的隊列,但這對他們來說將是一個重大改變,所以我很想發現一種方法來完成這項工作。

不是我依賴任何未定義的東西,但是如果他們願意依賴於IBM的特定行爲,我會留給他們。

回答

3

爲他們兩個的唯一途徑收到相同的消息是:

  1. 有消息的多個副本。
  2. 應用程序正在瀏覽消息而沒有鎖定,然後盤旋迴來刪除它。
  3. 應用程序正在撤銷一項交易並再次提供該消息。
  4. 連接在應用程序確認消息之前被切斷。

有多個應用競爭隊列中的消息是一種推薦的做法。如果有一個應用程序關閉,隊列仍然處於服務狀態在羣集中,這是至關重要的,因爲羣集將繼續將消息引導到未提供服務的隊列實例,直到滿足爲止。

如果是開發系統,請安裝SupportPac MA0W並告訴它只跟蹤一個隊列,並且您將能夠看到到底發生了什麼。

請參閱4.4節中的JMS規範。提供者絕不能傳遞確認消息的第二個副本。我在上面#4中介紹了4.4.13中的會話處理例外情況。這非常明確,是官方規範的一部分,因此不是IBM特定的行爲。

+0

Thanks T.Rob。多年來我沒有看過實際的規範,但我曾經想過,當隊列中有多個消費者(而不是一個主題)時,行爲完全未定義。但是也許「從來沒有提供確認消息的第二個副本」規定勝過了這一點。 – mindcrime

+0

這是未定義的競爭消費者之間的投遞順序。消息的傳遞也受到QOS設置的影響。如果應用程序指定了懶惰確認,那麼它可能會受騙。但是,如果郵件排隊等待並且未回滾或發生異常,那麼您只能進行一次和一次交付。 –

相關問題