4

私のキャリアの中で何度か遭遇した問題は、階層化されたサービス アーキテクチャで、すべてのスレッドがデッドロックまたはある種の無限ループで消費される状態になると、単一のダウンストリーム システムがクライアント アプリケーション全体をダウンさせる可能性があることです。そのシステムのバグ。このような状況下でも、Java EE サーバーのサーバー ソケットは、クライアント アプリケーションからの要求を受け入れてキューに入れています。これにより、クライアント アプリケーションは、適切に確立されたソケット接続からの応答を待っているすべてのスレッドを使い果たします。その後、すべてのユーザーの要求もキューに入れられるため、システムからロックアウトされます。

私はいくつかの解決策を考えましたが、コミュニティにもっと良い解決策があるかどうか疑問に思っていました.

  1. ダウンストリーム リクエスト用に分離されたスレッド プール。これが問題になるのは、システム内のアイドル スレッドの数を増やして、完全なスループットを確保するのに十分なスレッドが必要な小さなプールを多数作成するためです。スレッドを生成するということは、トランザクション コンテキストとセキュリティ コンテキストを自分で処理する必要があることを意味します。サポートされている Java EE ソリューションではありません。

  2. Java EE の推奨される非同期ソリューションである MDB ソリューションは、かなり重いように見えますが、アプリ サーバーが MDB スレッド プールの管理を処理できるという追加の利点があります。(現在、私のリストの第 1 位)

  3. ESB。これはさらに負荷が高く、ネットワークと処理時間が長くなります。ただし、個々のサービスのタイムアウトを設定できます。また、大企業に実装するには永遠にかかるという問題があるため、おそらく私の時間枠では実用的ではありません.

皆さん、もっと良いアイデアはありますか？

4

3 に答える 3

1

MDB のケースが通常の解決策であり、通常はタイムアウトもサポートされているため、リクエストがハングするのを防ぐことができます。そうは言っても、問題を実際に解決することはできませんが、応答がクライアントに返されることなく、バックアップを JMS キューに移動するだけです。もちろん、いくつかのサービスのうちの 1 つだけがこの問題を引き起こしている場合でも、他のサービスには引き続きアクセスできます。

あなたの提案 (1) は、commonj WorkManager を介して WebSphere または Weblogic でも実行できます。これらの環境でマネージド スレッドを作成でき、非常に軽量です。

WorkManager および TimerManager API

于 2008-11-17T20:46:07.200 に答える
0

Atomikos MessageDrivenContainers (メッセージ駆動型 POJO) を使用した軽量の MDB アプローチを試すことができます。アプリケーションはより軽量になり、テストしやすくなり、おそらくスケーラビリティも向上します。

見るhttp://www.atomikos.com/Publications/J2eeWithoutApplicationServer。

HTH

男

于 2009-06-02T20:11:56.160 に答える
0

システムがダウンしてもメッセージが失われないという利点があるデータベースにキューが永続化される MDB を使用します。

参加者間で非同期契約を確立することもできます。これが意味することは、クライアントがメッセージを送信し、多くの重い処理を行って応答を返すのではなく、単に確認応答を送信し、後で完全な結果を含む非同期メッセージをクライアントに送信するということです。

また、確立された時間内にクライアントが完全な応答を受信しなかった場合に、クライアントがメッセージを再送信できるようにするためのプロトコルを確立する必要があります。

于 2008-11-17T20:31:39.727 に答える