ActiveMQ が起動したときにこれらのサブスクリプションが準備できるように、activemq.xml で永続的なサブスクライバーを作成/事前構成する方法は? サブスクライバーがオフライン状態にあるかのように。
既知のサブスクライバーの固定数 (まだ構成可能) を期待しています。すべてのサブスクライバーが稼働していない場合に備えて、パブリッシャーから送信されたすべてのメッセージを 1 日目からバッファーに入れたい。これが一般的なシナリオかどうかはわかりませんが、助けてくれてありがとう。
ActiveMQ が起動したときにこれらのサブスクリプションが準備できるように、activemq.xml で永続的なサブスクライバーを作成/事前構成する方法は? サブスクライバーがオフライン状態にあるかのように。
既知のサブスクライバーの固定数 (まだ構成可能) を期待しています。すべてのサブスクライバーが稼働していない場合に備えて、パブリッシャーから送信されたすべてのメッセージを 1 日目からバッファーに入れたい。これが一般的なシナリオかどうかはわかりませんが、助けてくれてありがとう。
これは非常に一般的な使用例です。実際に確認する必要があるのは、永続的なトピックではなく、コンポジットの送信先です (この機能には多くの問題があります。主な問題は、メッセージがデフォルトで永続化されず、ブローカーの停止に耐えられないことです)。
このスキームを使用して、複合トピックを設定し、各メッセージを多数のキュー (サブスクライバーごとに専用のキュー) に転送します。
<destinationInterceptors>
<virtualDestinationInterceptor>
<virtualDestinations>
<compositeTopic name="orders">
<forwardTo>
<queue physicalName="orders.consumer1" />
<queue physicalName="orders.consumer2" />
</forwardTo>
</compositeTopic>
</virtualDestinations>
</virtualDestinationInterceptor>
</destinationInterceptors>
このようにして、サブスクライバーが最終的に独自のキューに接続すると、フィードされたメッセージが排出されます。
これらのキューに格納されたメッセージを処理するのに十分なメモリ制限があることを確認してください。そうしないと、ブローカがハングしたように見えます (プロデューサ フロー制御と呼ばれるブローカ機能)。
あなたは新しいユーザーであることがわかりました。これで質問に対する答えが得られた場合は、チェックを入れてください。
(トピックではなく) 永続的なキューの使用を検討し、キュー ブラウザー (サブスクライバー) を使用してメッセージを受信することができます。シーケンス番号を追跡する責任は、サブスクライバー側にあります(あなたのケースでそれが可能かどうかはわかりません)。キュー ブラウザは、永続キューからメッセージを削除しません。有効期限のあるメッセージを使用するか、一定期間後に通常のキュー サブスクライバーを使用して古いメッセージをフラッシュする必要があります。
永続的なキューを備えたキュー ブラウザーは、サーバーへの負担が少なくなりますが、サブスクライバーにより多くの負荷をかけています。
それが役に立てば幸い。