MQ JMS APIで既に消費されているメッセージを送信者がどのように知ることができますか？

Question

私はスタンドアロンのMQ JMSアプリケーションを扱っています。私たちのアプリは、クライアントが既にキューに入れられているメッセージプロデューサをすでに消費していることを認識する必要があります。クライアントアプリケーションは私たちの責任ではないためです。だから、 "msg.acknowledge（）;"のようなものを書くことはできません。彼らの側のもの（msg.acknowledge（）は私の状態では正しいアプローチではありません）。私はstackoverflowの歴史の答えを検索します。検索次は、かなり私が欲しいものと同じ：

https://stackoverflow.com/questions/6521117/how-to-guarantee-delivery-of-the-message-in-jms

Do the JMS spec or the various implementations support delivery confirmation of messages?

私の質問は、あるMQ APIまたはJMS APIでこれをアーカイブする他の方法がありますか？私はmsgの生産側でのみコーディングを行う必要があります、それはキューまたはトピックにすることができます。

もう1つの質問は、JMSの承認モードCLIENT_ACKNOWLEDGEですが、それは無関係ですか？私はいつも、このモードは、クライアントがメッセージを消費してmsg.acknowledge（）を呼び出すまでsend（）メソッドを呼び出すときにアプリケーションをブロックすることができると考えていますが、そうではないようです。プロダクトは、メッセージが配信された後にアプリケーションを終了するだけで、クライアントがacknowledge（）を呼び出すまで、メッセージはキューに格納されます。それは、メッセージがクライアントによって確認されるまで、プロデューサアプリがそこにハングアップすることを可能にしますか？

私のコンセプトが正しくない場合は、正解、ありがとう。

Answer 1

メッセージキューイングの主な目的は、プロデューサとコンシューマを切り離すことです。プロデューサは、消費者がメッセージを消費するのを待つ必要はなく、仕事を続けることができます。理想的には、プロデューサがメッセージがコンシューマによって処理されたかどうかを知る必要がある場合、消費者が別のキューにレスポンスメッセージを送信するのを待つ必要があります。

メッセージの確認はプロデューサとは関係ありません。メッセージ確認応答は、メッセージがアプリケーションに配信された後にメッセージをキューから削除するように消費者がメッセージングプロバイダに指示する方法です。

MQプロバイダなどのJMSプロバイダは、メッセージをアプリケーションに配信した後、メッセージングプロバイダにメッセージをキューから削除するように指示します。次に、メッセージを受信した後、アプリケーションが明示的にメッセージング・プロバイダにキューからメッセージを削除するように指示する、クライアントの肯定応答があります。

プロデューサーがコンシューマーがメッセージを受信するのを待たなければならない理由はありますか？ 1つの方法は、エレガントではありませんが、メッセージが送信されたら、送信されたメッセージのメッセージIDを使用して、そのメッセージを参照しようとします。メッセージが見つからない場合は、それが消費されたとみなすことができます