1

次の構成で ActiveMQ 5.6 を使用しています: - フロー制御オン - トピックのメモリ制限 1MB - ミラー キューが有効 (明示的な仮想トピックは定義されていません)

キューに送信される持続メッセージがありますQueueA。Mirror.QueueA明らかに、このメッセージは非永続的で自動的に作成されたトピックにコピーされます。

このトピックには、消費者はいません。ときどきコンシューマーがいる場合、それらは非永続サブスクライバーです。

しばらくすると、プロデューサーがブロックされ、次のエラーが発生します。

Usage Manager memory limit reached for topic://Mirror.QueueA

ActiveMQのドキュメントを含むさまざまな情報源によると、永続的なサブスクライバーのないトピックのメッセージは破棄されます。これは私が望んでいることであり、期待していたことです。しかし、これは明らかにそうではありません。

関連する StackOverflow の質問が 1 つありますが、承認された解決策では、フロー制御を使用し、ディスク スプーリングを無効にすることが提案されています。

これはディスクを使用せず、memoryLimit に達したときにプロデューサをブロックします。

しかし、コンシューマーが来ないために無期限にブロックされるため、プロデューサーをブロックしたくありません。これらのメッセージが保持されているのはなぜですか?

いくつかのオプションが表示されます: - これはバグであり、おそらく今後の AMQ バージョンで修正されます - この構成の問題 (解決方法はわかりません)ヒットしました（そのようなオプションが見つかりませんでした）

誰かが助けてくれることを願っています！

ありがとう、

//J

[アップデート]

すでに 5.6 のバージョンをフィールドに展開していますが、現在、同じ構成の AMQ の 5.8 インストールで同じ耐久性/負荷テストを実行しています。現在、5.6 システムの 10 倍のメッセージを問題なく送信しています。このテストを一晩中、または次の日に実行して、他に制限があるかどうかを確認します.

4

1 に答える 1

2

Ok、

以前の更新で述べたように、ストレージの超過を引き起こす同じ構成の ActiveMQ の 5.8 インストールで同じロード テストを実行していました。

これは、トピックのメモリ制限が 1MB の 3 つのキューに約 450 のトランザクションを送信した後に発生していました。KahaDB データベース ファイルのサイズが大きくなるのを見ることさえできます。

AMQ 5.8 では、4 日後に負荷テストを停止した結果、約 280.000 トランザクションが送信されました。ストレージの問題はなく、プロデューサのスタックはなく、KahaDB ファイルは常にほぼ同じサイズのままでした。

したがって、これが ActiveMQ 5.6 のバグであると断言することはできませんが、5.8 は明らかに動作が異なり、予想どおりであり、文書化されています。サブスクライバーが登録されていない場合、ミラーリングされたキューにメッセージを永続的に保存していません。

AMQ 5.6 の既存のインストールでは、アプリケーション コードの変更を避けるためにちょっとしたハックを使用しました。

  • アプリケーションが「Mirror」で始まるトピックから消費していたためです。<destinations>(デフォルトのプレフィックス) といくつかのワイルドカードを使用して、 XML タグを使用して構成で起動時にトピックを定義しました。ワイルドカードが使用された場所では、 のようなハードコードされた名前を使用しましたall-device。残念ながら、これは次のステップで必要でした。
  • 実際の (ミラー化された) キューから 1 つのトピックにすべてのメッセージ ( ) のコピーをルーティングする構成<compositeQueue>のセクション内にを定義しました。このトピックは、定義するだけではトピックも作成されないため、事前に定義するか、手動で作成する必要があります。さらに、使用できません<destinationInterceptors><forwardTo>compositeQueue
  • 次に、ミラー化されたキュー機能を構成から削除しました

要約すると、次のようになります。

    <destinations>
        <topic name="Mirror.QueueA.all-devices" physicalName="Mirror.all-devices" />
    </destinations>

    <destinationInterceptors>
      <virtualDestinationInterceptor>
        <virtualDestinations>
          <compositeQueue name="QueueA.*" forwardOnly="false">
            <forwardTo>
              <topic physicalName="Mirror.QueueA.all-devices" />
            </forwardTo>
          </compositeQueue>
        </virtualDestinations>
      </virtualDestinationInterceptor>
    </destinationInterceptors>

お役に立てれば。この「ハック」はすべての状況で可能であるとは限りませんが、個々のミラー トピックを使用したことがないため、これは可能でした。

于 2014-06-23T11:46:20.867 に答える