.net XMS中的IBM-MQ讀取器逐個確認處理後的消息

Question

我正在實現一個組件，該組件可以在特定隊列可用時讀取所有消息，但應該只能從隊列中異步刪除消息，消息內容已被處理並保留。我們讀取消息的速度比我們承認的要快（例如，我們可以閱讀10條消息，然後我們已準備好確認第一條消息）。當前的實現使用XMS API，但如果XMS不適合這些用途，我們可以切換到MQI。

我們嘗試了兩種方法來嘗試解決這個問題，但都具有使它們無法接受的缺點。我希望有人能提出更好的方法。

第一個實現在專用線程中使用IMessageConsumer來讀取所有消息並在其可用時發佈其內容。消息處理完畢後，調用message.Acknowledge()方法。會話由AcknowledgeMode.ClientAcknowledge創建。這種方法的問題在於，根據文檔，這會確認（並刪除）已收到的所有未確認消息。以上面的例子來說，這意味着所有10個讀取的消息都會在第一次調用時收到。所以這並不能真正解決問題。因爲讀的吞吐量，我們需要的，我們確實不能修改這個解決方案，以等待第一個消息的ACK讀取第二前等

第二個實施已決定的線程使用的IQueueBrowser閱讀所有郵件和發佈他們的內容。這不會在隊列讀取時從隊列中刪除消息。一個單獨的專用線程然後等待（在BlockingQueue上）已處理的消息的JMS消息ID。對於其中的每一個，它然後構造一個專用的IMessageConsumer（使用帶有JMSMessageID的消息選擇器）來讀取消息並對其進行確認。 （IQueueBrowser與專用IMessageConsumer的配對由XMS文檔關於隊列瀏覽器的部分推薦。）此方法的工作方式與預期相同，但正如人們所想象的那樣，它在MQ服務器上佔用CPU太多。

Answer 1

問題中提出的兩種方法似乎都依賴於應用程序的單個實例。使用多個應用程序實例，事務會話和COMMIT有什麼不對？性能報告（這些是SupportPacs，名稱類似MP **）都顯示吞吐量通過多個應用程序實例最大化，而水平縮放是您場景中最常用的方法之一。

這樣的設計可能是多個應用程序實例或同一個應用程序中的多個線程。讓它正常工作的關鍵是記住事務的範圍是連接句柄。這意味着多線程應用程序必須爲每個連接實例分配一個單獨的線程，並且在同一線程中讀取消息。

處理流程是，使用事務處理會話，應用程序針對隊列執行正常的MQGet，根據需要處理消息內容，然後發出MQCommit。 （我將在我的示例中使用MQ本機API名稱，因爲這不取決於語言）。如果這是XA事務，則應用程序將調用MQBegin來啓動事務，但對於單階段提交，假定事務。在這兩種情況下，MQCommit都會結束從隊列中刪除消息的事務。當消息處於同步點時，沒有其他應用程序實例可以檢索它們; MQ只提供下一個可用消息。如果事務回滾，則假定FIFO交付，任何線程的下一個MQGet都會檢索它。

有一些樣品中：
[WMQ install home]\tools\dotnet\samples\cs\xms\simple\wmq\
...而SimpleXAConsumer.cs是一個顯示此XA版本的示例。非XA版本更簡單，因爲您不需要外部協調器，動詞等。如果您從其中一個開始，請確保它們不指定排隊使用隊列，並且可以使用相同的配置啓動多個實例。或者，也可以採用包含創建連接，消息處理，連接關閉和銷燬的樣本部分，並將所有這些部分包含在線程spawner類中。

[插入瞭解使用最新版本的類的常用建議。]