タイムアウト状態 - 考えられる原因および修正
このファイルでは、 これらのタイムアウト状態をモニターするための一般的なタイマー変数およびツールをリストします。
最初に有効期限が切れるタイマーは、修正が必要な実際の問題を示さない場合があります。 タイムアウト状態を適切に診断するには、 特定のサーバント領域に有効なタイマー値をすべて知っている必要があります。
タイマーの一般タイプ | 考えられる原因 | 考えられるソリューション |
---|---|---|
入力 | クライアントがデータの一部だけを送信し、 残りのデータの送信が遅れた。 | クライアント側のアプリケーションは、 戻されたタイムアウト・マイナー・コードを受信する場合、 再試行ロジックの整備を検討する必要があります。 |
セッション | 使用されていないため、セッションがアイドルである。 | アイドル・セッションの失敗が問題である場合には、 パーシスタント・セッション・タイムアウトの値を増やすか、セッションをもっと頻繁に使用します。 |
WLM ディスパッチ | 次のいずれかの状態が原因で、
要求を自由にピックアップできるスレッドが存在しない。
いずれの場合でも、要求は、 サーバント (領域) にディスパッチされる WLM キューでの待機中にタイムアウトします。 |
すべてのスレッドが要求の処理に使用されている場合、次のいずれかの状態を示します。
|
トランザクション | トランザクション・タイムアウトの原因としては、
以下のことが考えられます。
|
『WLM ディスパッチ・タイムアウトに対する考えられるソリューション』を参照してください。 さらに、タイムアウトしたトランザクションに関与したリソースに対する競合を示すメッセージを参考にすることもできます。 |
出力 | 出力タイムアウトの原因として考えられるのは、 WLM ディスパッチの場合と同じです (ディスパッチは IIOP、出力は HTTP 用です)。 | 『WLM ディスパッチ・タイムアウトに対する考えられるソリューション』を参照してください。 さらに、 WebSphere 変数 protocol_accept_ http_work _after_min_srs=1 を使用して、WLM が最小数のサーバント領域を開始するまで HTTP トランスポート・ハンドラーが要求をディスパッチしないようにすることができます。 |