問題タブ [jms-topic]

Mule から JBOSS 5.1 トピックにサブスクライブする必要があります。これが私が使用している構成です。

クラスパスに次の jar を含めました。 -client.jar trove.jar

アプリを実行しようとすると、次のエラーが表示されます。誰かが私が使用すべき正確な依存関係の jar を教えてもらえますか?

springを使用してjmsトピックで同時実行を使用するには? キューの場合と同様に、maxConcurrentConsumers プロパティを目的の数に設定できます。しかし、JMS トピックに対してこれを行うと、同じメッセージを同時に消費することになり、望ましくありません。

誰かが私を正しい方向に向けることができますか?

ソニック トピックからメッセージを読み取り、Rabbit エクスチェンジにパブリッシュする、同期された Mule フローがあります。

ウサギを起動/停止すると、メッセージが失われます。Rabbit exchange は HA キューに発行しています。Rabbit Broker から適切な「Ack」を受信するまで、Mule がメッセージを消費しないようにするにはどうすればよいですか? これが流れです。

04/22 更新

Mule が 2 番目のブローカーに接続している場合の例外トレースを次に示します。これは私がメッセージを失うときです。

JMS トランザクションが AMQP アウトバウンド エンドポイントに追加されたときに受信した例外で 04/23 を更新:

スタンドアロン クライアントから Linux マシン上の JBoss 7.1 の JMS トピック実装にメッセージとオブジェクトをパブリッシュする際に問題があります。この場合、JUnit テスト ケースで接続をテストしています。

JMS トピックを介してオブジェクトを公開しようとしていますが、出力として NamingException が発生し続けます。

これは、MyTopic の Publisher を実装するクラスです。

クライアントが ConnectionFactory のルックアップを実行しようとすると、例外がキャッチされます。

私はすでに「ConnectionFactory」だけで試しましたが、まだnamingExceptionが発生しています。これは、ConnectionFactory を開く私の standalone.xml スニペットです。

InitialContex プロパティに何か問題がありましたか? 私はすでに同様の回答を見ていましたが、sudo bash standalone.sh -c standalone-full.xml で JBoss を起動して sandalone-full.xml に切り替えても問題は解決しませんでした。前もって感謝します。

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

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

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

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

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

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

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

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

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

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

ありがとう、

//J

[アップデート]

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

テスト用の簡単な構成があります。Stomp を介して最大 60 バイトのメッセージをトピックに送信する高速 C++ プロデューサー、低速コンシューマー、DROP に設定された address-full-policy です。

キューは、約 300,000 メッセージに相当する max-size-bytes に達するまで、毎秒数千のメッセージを受信して​​急速に成長します。HornetQ は期待どおりにメッセージをドロップし始めますが、それ以降はプロデューサーから 1 秒あたり 3 ～ 4 メッセージしか受け入れません。何が原因でしょうか？メッセージをドロップしている場合、プロデューサーから全速力でメッセージを受け入れることができるはずではありませんか?

私は Oozie ワークフローの自動化を進めています。自動化中に何百ものワークフローの結果を生成する際に、各 Oozie ジョブの状態を知ることが不可欠です。Oozie JMS 通知が役立つことを確認しました。oozie JMS 通知はトピックスで公開されています。とにかく、シェルスクリプトを介して通知を取得できる場所にクエリがあります。または、Java コードを使用することが唯一のオプションです。