4

私は ActiveMQ をメッセージ ブローカーの候補として評価してきました。ActiveMQ のパフォーマンスの制限を理解するために、いくつかのテスト コードを作成しました。

次のようにできるだけ早くメッセージを送信することで、ブローカーで失敗状態を生成できます。

try {
    while(true) {
        byte[] payload = new byte[(int) (Math.random() * 16384)];
        BytesMessage message = session.createBytesMessage();
        message.writeBytes(payload);
        producer.send(message);
} catch (JMSException ex) { ... }

驚いたのはそのライン

producer.send(message);

ブローカが失敗状態になるとブロックします。何らかの例外がスローされることを期待していたので、ブローカーが失敗したという兆候があるでしょう。

テスト コードがブローカーにスパムを送信していることに気付きました。ブローカーが失敗することを期待しています。ただし、単にブロックするのではなく、ブローカーが「大声で」失敗した方がよいと思います。

これは非現実的な期待ですか？

アップデート：

Uri の回答は、3 月に提出された ActiveMQ バグ レポートを参照しています。バグの説明には、私が探しているもののように聞こえる提案が含まれています。待っているスレッドを構築するよりも。」

ただし、8 か月後、バグは現在 1 票で割り当てが解除されています。だから私は疑問がまだ残っていると思います.これはActiveMQが実装すべき(実装する?)ものですか?

4

3 に答える 3

5

すべてのメッセージブローカーが対処しなければならない「遅いコンシューマー」とプロデューサーのフロー制御の問題をテストしています。プロデューサーを失敗させたり、ブロックしたり、ディスクにスプールしたりしますか？

基本的に、ActiveMQのデフォルトのデフォルトは、プロデューサーをブロックすることです。ただし、ディスクにスプールするようにメッセージカーソルを設定できます。

ところで、キュー/トピックを使用しているのか、永続的/非永続的を使用しているのかは、まだ言っていません。非永続的なトピックを使用している場合は、メッセージなどを破棄するために使用できる他の戦略があります。

于 2008-12-05T16:02:05.537 に答える
1

どうやら既知の問題があり、修正されたかどうかは不明です。

https://issues.apache.org/activemq/browse/AMQ-1625

于 2008-12-05T16:05:14.797 に答える
0

ActiveMQ の設定についてはわかりませんが、他の JMS プロバイダーにはさまざまな設定オプションがあります。そのため、その状況で ActiveMQ を希望どおりに実行できる可能性があります。

この状況でプロバイダーがブロックするかどうかを指定するオプションが Fiorano にあることは知っています。

于 2008-12-05T15:08:30.077 に答える