1

スタンドアロン アプリケーションで (いくつかの jms トピック用に) メッセージ リスナーを作成する必要がありました。受信した各メッセージは何らかの処理を行う必要があるためです。

この振る舞いは私のパフォーマンス全体を遅らせます。

そこで、メッセージ リスナーに一種の POOL を作成することにしました。(ejb の MDB のように)。

私はこのようにExecutorクラス(Java)を使い始めました:

import java.util.concurrent.Executor;
import java.util.concurrent.Executors; 

    private Executor threadPool = Executors.newCachedThreadPool();
    @Override
    public void onMessage(final Message msg)
    {
        Runnable t = new Runnable()
        {
            public void run()
            {
                execute(msg);
                log.trace(received messge");
            }
        };
        threadPool.execute(t);
    }

public void execute(Message msg)
{
   // do some long running process)
}

このようにして、実行ごとに個別のスレッドを作成することにより、処理中にアプリケーションがメッセージから別のメッセージにスタックしないようにします。

私はあなたの経験からあなたの提案をしたいと思います..実装が将来問題を引き起こす可能性がある場合、その種類はありますか? 何に注意する必要がありますか(同時実行性が問題であることはわかっています)?

4

1 に答える 1

3

これは JMS です。なぜ MDB をプールしないのですか? これにより、別のスレッド プールを持つことを避けることができます。また、途中でアプリケーションをシャットダウンしても、未処理のアイテムが失われることはありません。

キャッシュされたスレッド プールと固定されたスレッド プールの違いを理解していることを確認してください ( Java の newCachedThreadPool() と newFixedThreadPoolを参照)。それはあなたが望むものかもしれませんし、そうでないかもしれません。開いているスレッドの最大数を事前に知りたいので、通常は固定スレッド プールを使用します。

ちょっとしたことですが、メッセージを処理する前に (同様に) ログを記録して、メッセージが処理された時間を簡単に把握できるようにします。固定プールを使用した場合は、キューに入れられた時間を知ることも重要です。

于 2012-10-28T14:14:46.413 に答える