メッセージを受信してバッチを処理する MDB があります (BatchProcessor)。一度にバッチ内の 1 つの項目を処理する代わりに、BatchProcessor は BatchItemProcessor を作成し、Semaphore を使用すると、一度に最大数の項目を同時に処理できます。BatchItemProcessors はステートレス セッション Bean であり、Glassfish コンテナーによって注入されます。
バッチ アイテムとそのステータスの処理が終了するたびに、SOAP メッセージを別のサービスに送信する必要があります。BatchItemProcessor は、JMS トピックにメッセージを作成/送信します。このメッセージをリッスンし、SOAP メッセージを作成して他のサービスに送信する別の MDB である StatusSender があります。
問題は、すべてのバッチ項目が BatchProcessor によってディスパッチされるまで、SOAP メッセージが送信されないことです。
ログを見ると、BatchItemProcessors は EJB スレッド プール (例: ログからの名前__ejb-thread-pool10) で作成されており、BatchProccessor と StatusSender は、Glassfish MDB スレッド プール (例: ログからの名前) で作成されていますp: thread-pool-1; w: 39。
p: thread-pool-1;プールとw: 39実際のスレッドを識別する (確認/拒否するドキュメントが見つからないため) と仮定しています。これが true の場合、スレッド識別子が異なるため (BatchProcess 用に 1 つ、StatusSender 用に複数)、BatchProcessor は StatusSender とはまったく異なるスレッドを使用します。
つまり、StatusSender の onMessage 呼び出しを実行する前に BatchProcessor の onMessage を完了する必要がある理由について、私は本当に混乱しています。
Glassfish EJB コンテナー/MDB 設定の構成 (default-config と server-config の両方) を見ると、次のようになっています (これがデフォルトだと思います)。
- 初期および最小プール サイズ = 0
- 最大プール サイズ = 32
- プールのサイズ変更量 = 8
- アイドル タイムアウト = 600
誰かがこの問題について私を助けてくれたら、それは非常にありがたいです. また、優れたリソース (本、ウェブサイトなど) の推奨事項もいただければ幸いです。
アップデート
私の問題は、StatusSender onMessage の実行の遅延を引き起こしているコード ロジックに関連していました。ただし、Glassfish とスレッド/プールに関する適切な参考資料として、引き続き推奨事項をいただければ幸いです。