- ベストアンサー
コネクションプーリングの枯渇
tomcat-Servletでの開発を行っています。 ＭＶＣモデルでのＷＥＢアプリケーションです。 ＤＢへの接続用として自作のコネクションプーリングを使用しています。 （プーリング数は２０を設定） 基本的なＳＱＬ実行フローは下記のようになります。 １．コネクションプーリングを取得 ２．ＳＱＬ文を実行 ３．コネクションプーリングを返却 ところが、時間を置いて psコマンドで確認すると、 だんだん数が減っていっているようです。 原因を調査しているのですが、 もし次のような原因で正しいかどうか分かりましたらご連絡ください。 ＜考えている原因＞ 要するに上記の３（返却）がされていないのであって。 ・実行処理中に利用者がクライアント側のブラウザを落としている。 と仮説を立てているのですが。 この仮説が正しいかどうか、 また、もし正しい場合には、どうすれば回避可能かをご教授ください。 補足の必要があればご連絡ください。 （コネクションプーリングの全文を載せたいのですが、 長すぎるようで・・・）
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
仮説に関してはログ状況をみれば判明すると思います。 単純にロジックで返却しわすれているところがあったりするかもしれません。 （とくに外注を多く使っている場合はよくあります） ブラウザ側で途中終了した場合でもサーバー側のスレッドは流れているはずなので、単純な業務ロジックのミスだと考えるのが妥当だと思いますが。 時間がなければ、コネクションマネージャーを作成して、コネクションの状況を監視させて強制的にプールに返却するのもいいかもしれませんね。 （これは以前にやった記憶があります）
その他の回答 (3)
- hidebu-
- ベストアンサー率53% (45/84)
実験してみればわかるとおもいますが broken pipeになっても１リクエストに対して対応する1スレッドは異常がない限り流れます。 1分間スリープで止めた後に何かしら処理をするロジックをかいてみると、リクエストをしたあとに即ブラウザを落としても、処理が続行されているのが確認できます。 ですから、業務ロジックでの例外処理等のミスで返却処理が省略されてしまっていると考えるのが一番妥当なのです。 そして、結合テスト以降のフェーズになるとロギングの粒度の細かさで原因追求の精度がきまってきます。 業務ロジックのほうにロギング処理をいれるのがきついのであれば、プールのほうでコネクション取得時にＩＤを付与し（ハッシュコードでよいでしょう）時刻と取得した旨をログ出力 返却されたときに同じようにログ出力をしてみて、使用状況を把握できるようにしておくのがよいかと。 コネクションマネージャは単に取り出された時刻を記憶しておき、正常処理時にはありえない時間が経過しても返却されていなければ強制的にプールに返却するようにするだけです。
お礼
お返事おそくなりましたことお詫びします。 ブラウザを落としても、 処理が続行されていることが確認できました。 業務ロジックの見直し作業も終了しましたので、 あとはログ情報から少々様子を見て今後の対応を計ります。 いろいろとありがとうございました。
補足
補足遅れましたことお詫び致します。 上記「スレッド」というのは、 いわゆるRunnable実装のスレッド（Thread）を使用して ＤＢの検索や更新を行うということでしょうか？ あるいは、 もしサーブレットのみのプログラムであった場合でも、 リクエスト中にブラウザを落としても、 処理は最後まで実行されるということでしょうか？ （Responseだけがない状態。） 現在自作のプーリングを使っているのですが、 オライリー「Javaサーブレットプログラミング」（くま本） を買ってきました。 この中にプーリングサンプルがあったので、 こちらを勉強してみたいと思います。 ありがとうございます。
- davosuke
- ベストアンサー率61% (34/55)
>以下の点、ついでにお伺いしたいと思います。 >・結局のところ上記の仮説は正しいのでしょうか？ システム全体が見えないので、なんともいえませんが 確かに上記の仮説も正しいと思いますが、それだけではないかもしれません。それが何といわれれば、わかりかねますが、トラフィックをかけ高負荷状態のテストしてたら 何かわかるかもしれません。 >・EJB（？）、J2EE、JNDI、各APサーバなどのプーリング>機能を使うと、枯渇するといったことは無くなるの >でしょうか 前に携わったシステム開発で軽減しました。 AP側の問題もあるかもしれませんので 確実ではありませんが・・・・・・・・ 以上、補足回答します
お礼
ありがとうございました。 とりあえず今回は、 全体のＳＱＬ文を見直し、処理速度を上げることで、 「ブラウザ終了」のされにくいシステムにしようと思います。 （現状「待ちきれない」ところに原因があるのではないかと・・・） ＪＮＤＩとしても導入に時間がかかるため、 こちらは今後順次対応していきたいと思います。 ありがとうございました。
- davosuke
- ベストアンサー率61% (34/55)
EJBのプール機能を使ってみてはどうですが、 貴方様の開発の現状からST（システムテスト）等のフェーズなのでいまさらEJBの導入するのはどうかと思いましたが、アドバイス程度でお願いします。 メリット (1)EJBのプール機能を使いDBサーバの負荷を軽減させる。 (2)サーブレットとDB巻のフィルタに役割を担う デメリット (1)EJBに対してある程度の設計製造期間が必要
補足
さっそくの回答ありがとうございます。 確かに自作のところに問題があるのかもしれません。 以下の点、ついでにお伺いしたいと思います。 ・結局のところ上記の仮説は正しいのでしょうか？ ・EJB（？）、J2EE、JNDI、各APサーバなどのプーリング機能を使うと、 枯渇するといったことは無くなるのでしょうか？
補足
ありがとうございます。 私のほうでも返却忘れではないかと調査しましたが、 どうやらそうではないようです。 全てのソースを確認し返却忘れがないことを確認しました。 > ブラウザ側で途中終了した場合でもサーバー側のスレッドは流れているはず このあたりについて少々詳しくお教え頂ければと思います。 コネクションマネージャについては、 これから調べてみます。