ネットワークタイムアウトでちょっとハマったことがあったため、注意すべき点をまとめておきたいと思います。アドレスのアイドルタイムアウトが与える影響について、いくつかのケースを例に考えていきます。デプロイメントモデルを前提としています。分間でタイムアウトする仕様となっています。アドレスの「構成」から確認することができます。続いて、このタイムアウト値が与える影響について、いくつかのケースを確認していきます。上で共有しているようなケースですね。(実際は仮想ネットワークがありますが簡略化しています。接続でコネクションプーリングを使用する場合に問題となることがあります。接続するのではなく、接続をあらかじめプールしておいて使い回すことでアプリケーションの性能を高めるためのものです。アイドルタイムアウトの場合に問題が発生します。側で切断されるため、プールされているけれど実は死んでいる接続となります。このコネクションをアプリが使用するとソケットエラーとなります。アイドルタイムアウトを延ばせばエラーは起きなくなりますが、TCPセッションが残っていくためリソース面が懸念されます。コネクションプーリングには、プールされているコネクションが生存しているか(DB側で切断されているケースなど)をチェックする仕組みが実装されているので、これを使用します。validationInterval="60000"ここでは、コネクションプーリングの実装には言及しません。DBCP、各種アプリケーションフレームワークでおおむね上記のようなパラメータが実装されていますので、具体的な設定は各ドキュメントをご確認ください。アプリをデプロイしているケースです。ブラウザ側にいつまでたっても応答が返ってこないという現象が発生します。分以上って、そもそも・・・という話は置いておきます。パケットも返ってこないため、ひたすら待ちになり、ブラウザにエラー画面も表示されない状態になります。対策としては、タイムアウトを下記の設定とする必要があります。側でクエリタイムアウトを設定する手もあります。接続セッションを張っておきたい場合も同様に注意が必要です。クライアントツールを接続するケースでの対策を紹介します。実行すると接続セッションが破棄されているためエラーとなります。設定できればよいのですが、標準機能でないためちょっと工夫が必要でした。ファイルを任意の場所へ展開します。バージョンと同じバージョンンのものをダウンロードします。