1

5 分ごとに 2 つのタイマーを呼び出して (ファイルがディレクターに存在するかどうかに基づいて) 送信し、キューからメッセージを受信するスタンドアロン アプリケーション (アプリ サーバーなし) を設計しています。このアプリケーションは、長期間 (年) 継続して実行する予定です....

今、私はJMS接続を一度だけ作成してそれを常に使用するか、5分ごとに接続してそれらを閉じるか、ジレンマを抱えています...（ビジネスロジックを実行した後）

デザインに関する提案は役に立ちますか? 単一の接続を使用する (そして JMS MessageListenr を使用する) 場合、キュー マネージャーがダウンして 1 日か 2 日後に来るとどうなりますか.......

ActiveMQ でサンプルを試してみました...アクティブな mq ブローカーとプロデューサーを強制終了するとすぐに...リスナー スレッド (conn を 1 回だけ作成し、MessageListener を使用) アプリケーションは数分後に自動的に終了します

// 以下のリスナーコード

    connectionFactory = new ActiveMQConnectionFactory(
            ActiveMQConnection.DEFAULT_USER,
             ActiveMQConnection.DEFAULT_PASSWORD,
            ActiveMQConnection.DEFAULT_BROKER_URL);
     connection = connectionFactory.createConnection();
     connection.start();
     session = connection.createSession(transacted, Session.AUTO_ACKNOWLEDGE);
     destination = session.createQueue("mmy first active mq queue");

    MessageConsumer consumer = session.createConsumer(destination);
    MyListener mylistener = new MyListener();
    consumer.setMessageListener(mylistener);
    connection.setExceptionListener(mylistener);
4

3 に答える 3

0

ActiveMQでは、1つの接続を使用することが可能であり、優れたソリューションになる可能性がありますが、もちろんアプリケーションによって異なります。ActiveMQは、アプリで利用できる接続プールメカニズムを提供するライブラリを提供します。標準のActiveMQConnectionFactoryを使用する代わりに、PooledConnectionFactoryを使用し、アプリケーションが使用するConnectionインスタンスのカバーの下でプールされます。

接続が必要になるたびに、ファクトリは未使用の接続をプールから返すことができ、各接続には一連のセッションをプールすることもでき、接続とセッションを起動するために必要な割り当てとワイヤレベルのチャタリングの量をさらに減らすことができます。

あなたが探求することができる主題に関するいくつかの興味深いブログがあります。

SpringでActiveMQを使用するActiveMQのプールされた接続

コードサンプルを探すもう1つの場所は、ActiveMQソース自体です。モジュールには、プールの動作を示すいくつかの単体テストがあります。

于 2013-02-17T17:30:16.213 に答える
0

私の意見では、深刻な理由から、単一の接続は非常に悪い選択になります。

  1. 特殊なケース（切断、転倒など）により、リスナーが転倒する（そして再度リッスンしない）場合があります。

  2. Javaのメモリ消費量が望ましくないレベルに達する可能性があります。

  3. プログラムは常に変更する必要があるため、1つの接続での作業はそれほど動的ではありません。

キューの大きな利点は、取得したメッセージを必要なだけ長く保持できることです。したがって、プログラムが非同期で動作できる場合は、接続を続行する理由はありません。

于 2013-02-17T13:36:22.923 に答える
0

どのメッセージング システムでも、警告を発するために、ある時点で接続の再試行時にプログラムをタイムアウトさせるという要件に常に直面します。たとえば、QMgr が実際に 1 ～ 2 日間ダウンしていた場合、再接続の試行を警告なしに 2 日間待機するのをブロックするのではなく、接続が失われてから数分以内にアプリにそのイベントをログに記録させたいと思うでしょう。

その要件を考慮して、最初にすべきことは、メッセージング エンジンへの接続試行と例外処理を含むシーケンスをループするようにアプリケーションを設計することです。そのループ内では、接続が存在すると想定して、キューへのハンドルを維持するか、必要に応じてキューを開いたり閉じたりすることができます。この内側のループ内でポーリングを駆動するか、反復ごとに正常に終了し、必要に応じて外側のループで接続を再駆動させます。

外側のループが存在する限り、メッセージング エンジン側で接続が失われても、アプリは継続的に実行できます。(この応答の一般的な部分のキュー マネージャーなどのベンダー固有の用語を避けるために、「メッセージング エンジン」を使用しています。)

WebSphere MQ を使用する場合は、マルチインスタンス HA QMgr を使用してアプリケーションを実行しながら、QMgr をアップグレードするなどの操作を実行できます。アプリは、コードを変更せずに実行中の QMgr の半分にシームレスに再接続し、2 フェーズ コミットが必要な場合は XA を使用できます。ライブ QMgr が見つからずに再接続ポーリングが構成済みのしきい値を超えた場合、アプリはエラー コードを受け取り、それを使用してアラートを生成できます。

最後に、アプリが 5 分ごとに再接続する必要があるかどうかの問題は、WMQ QMgr 自体には何の違いもありません。TLS チャネルを使用する場合でも、QMgr の追加の負荷は無視できます。主な考慮事項はチャネルの起動時間ですが、5 分間のポーリングでは、ショーストッパーの問題になる可能性は低いと考えられます。他のトランスポートには問題があるかもしれないし、ないかもしれませんが、私は彼らと話す資格がありません. WebSphere MQ に関する限り、何の問題もありません。小さな QMgr でも数千の同時接続を処理できます。reconnect-on-each-poll メソッドには、ノイズの多いネットワーク環境で発生するエラーが少ないという利点があります。これは、不安定なネットワーク上で継続的な接続を維持するよりも、簡単に接続を取得して正常に終了する方が簡単だからです。したがって、アプリとサーバーが同じデータセンターにある場合は、どちらのオプションも機能します。それらが WAN 経由で接続されていて、ファイアウォールのタイムアウトやその他の中断の影響を受ける場合は、接続が短い方がよい傾向にあります。

于 2013-02-18T22:16:27.517 に答える