多線程JMS代碼：CLIENT_ACKNOWLEDGE或交易會話

Question

編輯過的問題：我正在研究多線程JMS接收者和發布者代碼（獨立的多線程Java應用程序）。 MOM是MQSonic。 從隊列接收XML消息，調用存儲過程（執行需要70秒），並在90秒內將響應發送到Topic。 當代理關閉或應用程序按計划關閉時，我需要處理一個條件。 例如，從Queue接收消息並在Java中對其進行處理的情況，同時Queue和Topic都將關閉。 然后，要處理那些不在隊列中且未發送到主題但在Java內存中的消息，我有以下選擇：

（1）創建CLIENT_ACKNOWLEDGE會話為：connection.createSession（false，javax.jms.Session.CLIENT_ACKNOWLEDGE）在這里，我僅在成功完成事務（存儲過程）之后才確認消息。

（2）使用事務會話，即connection.createSession（true，-1）。 在這種方法中，由於事務（存儲過程）中的某些異常，消息被回滾並重新傳遞。 它們一次又一次地回滾，並一直持續到我終止該程序為止。 我可以限制從隊列重新發送jms消息的數量嗎？

另外在上述兩種方法中哪一種更好？

Answer 1

接口progress.message.jclient.ConnectionFactory具有方法setMaxDeliveryCount(java.lang.Integer value) ，您可以在其中設置將消息重新發送到MessageConsumer的最大次數。 當達到此次數時，它將被移至SonicMQ.deadMessage隊列。

您可以在第210頁的《 Sonic MQ應用程序編程指南》（版本7.6）中進行檢查。

至於關於哪個更好的問題，這取決於存儲過程是否要執行多次。 如果存在問題，則應使用跨JMS隊列和數據庫的事務（Sonic支持XA事務）。 如果您不介意執行多次，那么當您發現代理已關閉時（很可能是您嘗試確認消息時），我將不確認消息並中止處理。 這樣，如果第一個處理器在連接失敗后無法處理該消息，則另一個處理器能夠處理該消息。

如果消息處理時間可變，您可能還需要查看Sonic JMS會話的SINGLE_MESSAGE_ACKNOWLEDGE模式。 通常，在消息上調用acknowledge()還會確認之前的所有消息。 如果您不按順序處理它們，那不是您想要的事情。 在單消息確認模式下（不是JMS標准）， acknowledge()僅確認在其上被調用的消息。

Answer 2

不知道您正在使用哪個消息傳遞提供程序，我不知道這是否會對您有所幫助。

MQ Series消息具有一個回退計數器，可以通過在隊列上配置強化回退計數器選項來啟用。
當我以前遇到此問題時，請執行以下操作：

// get/receive message from queue

if ( backout counter > n ) {
   move_message_to_app_dead_letter_queue();
   return;
}
process_message();

MQ系列標題字段可作為JMS屬性訪問。

如果可以使用XA事務同時回滾或提交數據庫和隊列管理器，則使用上述方法也將有所幫助。
但是，XA事務確實會導致明顯的性能損失，並且使用存儲的proc可能無法實現。

另一種方法是將消息立即作為Blob寫入message_table，然后從隊列中提交消息。
在message_table上放置一個觸發器以調用存儲的proc，然后將JMS響應機制添加到存儲的proc中。

Answer 3

如果您擔心與可能發生故障的消息隊列/代理/服務器/等進行通信，以及如何中斷正在嘗試設計的較大流程的總體流程，那么您可能應該研究支持集群的JMS隊列服務器的數量，因此當群集中的各個服務器出現故障時，您仍然可以可靠地生成/使用消息。

Answer 4

您的問題不是100％清楚，但是似乎問題是您在處理本來不應該的消息時拋出異常。

如果消息實際存在問題，例如xml格式錯誤或根據您的數據模型無效，則您不希望回滾事務。 您可能想記錄該錯誤，但是您已經成功處理了該消息，在這種情況下，只是“成功”表示您已將消息標識為有問題的。

另一方面，如果在處理消息時由於消息外部的某些問題而出現問題（例如，數據庫已關閉或目標主題不可用），則您可能確實想回滾事務，但是您也希望想要確保在問題解決之前停止使用消息，否則您將遇到上述場景，不斷重復處理同一條消息，每次嘗試訪問當前不可用的資源都會失敗。