これが私のシナリオです。このプログラムは、パブリッシャー/サブスクライバーの方法論で開発されています。プロデューサー部分とコンシューマー部分に 2 つのトピック (topic1、topic2) があります。プロデューサー プログラムのコンシューマーから受信したトピック 1 の確認を取得する必要があるため、確認ステータスが true の場合、プロデューサー プログラムはトピック 2 でメッセージを送信する必要があります。
session.CLIENT_ACKNOWLEDGE消費者に示唆するグーグルリンクがありました。しかし、さらなる処理のために確認ステータスをプロデューサーに返す必要があります。
JMS仕様では、メッセージがサブスクライバーによって消費されたかどうかをパブリッシャーが知るためのAPIは定義されていません。パブリッシャーはメッセージを発行するだけで、そのメッセージをサブスクライバーに配信するのはメッセージングプロバイダー/ブローカーです。サブスクリプションがある場合、ブローカーはメッセージを配信します。それ以外の場合、そのメッセージは破棄されます。
このsession.CLIENT_ACKNOWLEDGEオプションは、コンシューマーがメッセージングプロバイダー（プロデューサーではない）にメッセージをキュー/メモリから削除するように指示する方法の1つです。他にもいくつかの確認応答オプションがありますが、これらのオプションはすべて、メッセージングプロバイダーにメッセージを削除するように指示するためのものですが、プロデューサーには通知しません。
プロデューサーがコンシューマーからの確認応答を必要とする場合、コンシューマーは別のトピックに関する確認応答メッセージを公開する必要があり、プロデューサーはそれらの確認応答を受信するためにそのトピックにサブスクライブします。例えば：
プロデューサーはプロデューサーに公開しますTOPIC1
プロデューサーはサブスクライブしますTOPIC1/ACKS
コンシューマーはサブスクライブしTOPIC1
ますメッセージを受信した後
コンシューマーは確認メッセージを公開しますTOPIC1/ACKS
プロデューサーは確認メッセージを受信します。
その後、TOPIC2で公開できます
TOPIC1には複数のサブスクライバーが存在する可能性があるため、複数の確認応答メッセージが存在する可能性があることに注意する必要があります。
プログラムに含まれるメッセージ プロデューサーが 1 つだけの場合は、メッセージ コンシューマーにキューを作成し、プロデューサーがそのキューをサブスクライブできるようにします。キュー モードでは、ポイント ツー ポイントです。したがって、メッセージはコンシューマーからプロデューサーにのみ配信されます。
または、 setJMSReplyToメソッドを使用して、プロデューサーからメッセージを受信したときにコンシューマーが応答するキューを指定することもできます。この方法では、コンシューマーで明示的にキューを作成する必要はありませんが、プロデューサーでもキューを作成できます。ただし、プロデューサーがそのキューをリッスンして確認を受信できるようにする必要があります。