単純なRabbitMQテストプログラムがランダムにメッセージをキューに入れ、別のプログラムがそれらを読み取り、すべてSpring-AMQPを使用しています。コンシューマーが死亡した場合（たとえば、接続またはチャネルを閉じる機会がないままプロセスを強制終了した場合）、確認応答されなかったメッセージは、永久に未確認のままであるように見えます。
接続がない場合にチャネルが停止し、残りの未確認のメッセージが再配信されるという多くの参照（たとえば、この質問）を見てきました。これは私が見ている動作ではありません。代わりに、IDLEとマークされたチャネルのリストと、実行中とマークされているがアクティビティがない接続のリストが増えています。
プロセスが強制終了された後、接続が切断されたことを通知するために必要な構成はありますか？
編集： VirtualBox VM内でrabbitmqサーバーを実行していましたが、NATを介したデッドインバウンド接続を正しく管理していないようです。これは、物理ホスト上で直接実行されているmqサーバーで問題なく機能します。
AMQPはキューと交換を使用します。取引所で公開し、取引所からメッセージを取得するためにキューをバインドします（私のブログで簡単な説明を見ることができます。キューを作成するときに、自動削除と、その前に未使用のままになる時間を設定できます自動削除。RabbitMQquickrefからの引用は次のとおりです。
queue.declare（short reserved-1、queue-nameキュー、ビットパッシブ、ビット耐久性、ビット排他、ビット自動削除、no-wait no-wait、テーブル引数）➔declare-ok
サポート：キューを完全に宣言し、必要に応じて作成します。
このメソッドは、キューを作成またはチェックします。新しいキューを作成するとき、クライアントは、キューとその内容の耐久性、およびキューの共有レベルを制御するさまざまなプロパティを指定できます。
RabbitMQは、キューの作成者がその動作のさまざまな側面を制御できるようにするAMQP仕様の拡張機能を実装しています。
キューごとのメッセージTTLこの拡張機能は、キューに公開されたメッセージがサーバーによって破棄されるまでの存続期間を決定します。存続時間は、このメソッドのargumentsパラメーターに対するx-message-ttl引数を使用して構成されます。
キューの有効期限キューは、オプションのリース時間で宣言できます。リース時間は、キューがサーバーによって自動的に削除される前に、キューが未使用のままでいられる期間を決定します。リース時間は、このメソッドのargumentsパラメーターのx-expires引数として提供されます。
ミラーリングされたキューキューのアクティブ/アクティブ高可用性を開発しました。これは、RabbitMQクラスター内の他のノードでキューをミラーリングできるようにすることで機能します。その結果、クラスターの1つのノードに障害が発生した場合、キューは自動的にミラーの1つに切り替わり、サービスを利用できなくなることなく動作を継続できます。ミラーリングされたキューを作成するには、このメソッドのargumentsパラメーターにx-ha-policy引数を指定します。
終了するために答える。これは実際の問題ではないことが判明しました。
私はVirtualBoxVM内でrabbitmqサーバーを実行していましたが、NATを介したデッドインバウンド接続を正しく管理していないようです。これは、物理ホスト上で直接実行されているmqサーバーで問題なく機能します。