問題の説明：
テストプロセスにおけるシステム座る、しばしば突然アクセスすることはできませんが、アクセスできない突然、その後、その後、いくつかの時間のためにサービスを再起動し、正常に実行することができ、システムは仮死状態に表示されますので、繰り返し！
万能薬を再起動し、それは真剣にテストSITの進行に影響を与えるに応じて問題を解決することはできませんが、あなたが出て、なぜ見つけ、できるだけ早く解決し、この問題は、生産のシステムがないので必要があります。
問題の分析と解決プロセスのアイデア：
以下に説明するように図1に示すように、システムに問題がある、プログラマは、最初のログ分析は、最初のセッションが確立されていないディスプレイまたはタイムアウトである！（セッションタイムアウト）
処理コード解析E4AとCMISセッション、および何も間違っているを発見しました。
ログイン-------- -----------
10：11：43.047 [HTTP-8080から6] ERROR cmffsfilter.MideaSSOLoginFilter - SSOクライアントは53F0A1AD92CA1126F1D22C0291F6CED3をセッションID
【2016年10月21日10：11：43049 INFO]要求を受け入れ：/cmis.ecf/queryPAuthList.doを
[2016年10月21日10：11：43049 DEBUG]セッションを介して、ユーザーのロケール設定を取得...
【2016年10月21日10：11：43049 DEBUG]処理要求：/cmis.ecf/queryPAuthList.doが例外をスローします。
com.ecc.emp.session.SessionException：セッション確立していないか、タイムアウト！
ログイン-------- ----------
2は、（以下ログ）最初に与えられている場所を見つけ、ログを分析していきます。名前WFDataSourceは、このコンテキストでバインドされていません、
システムは、データ・ソースが見つからなかったことを文脈手段を考えると、それは、接続要求データソース内のエラーです。
2016年10月21日15：50：50134 INFOトランザクション - データソースからの新しい接続を適用します...
2016年10月21日15：50：50135 ERRORデータソース - データソースの初期化に失敗しましたのjndiName =で、java：comp / env / WFDataSource
javax.naming.NameNotFoundExceptionが：名前WFDataSourceは、このコンテキストでバインドされていません
org.apache.naming.NamingContext.lookupで（NamingContext.java:770）
データベースへの3は、2によると、後続の要求につながる、占領されている構成データベースの接続プールTomcatの接続に起因して、あなたのお母さんの度合いを総合的に分析を見つけることが、リリースされていないことはできなくなりまし接続しないで
したがって、署名することができない、仮死状態に表示されるシステムを引き起こし、エラー。
図4は、データ・ソース接続の構成図のTomcatは20であることがMAXACTIVEパラメータ（最大接続数）について見出され、すなわち、オンにしないremoveAbandoned（接続回復を開始する）デフォルトはfalse。
20の以上の接続が、要求がデータソースに接続できない場合には、問題になります。あなたは、接続の数を確認するために、データベースのモニターを表示することができます。
図5は、4つの分析によるとのみ接続数を増やすことができ、ちょうど十分、MAXACTIVE 50、開いていないremoveAbandonedを変更するだけで始めた接続か、または問題が繰り返されます。
問題が解決され、週に悩まさ6、最後に変更MAXACTIVE 200、およびremoveAbandoned =「true」を、removeAbandonedTimeoutを=「180」（自動回収タンク接続タイムアウト180秒）、！
最後に、TOMCAT DBCPデータソース接続は、説明を配置アタッチ：
Tomcatのデータベース接続プールを使用する場合、以下のパラメータは、タイムアウトには、2人のマークされた赤色タイミング回復接続リソース解放を添加すべきです。
INITIALSIZE：接続プールが開始初期接続の数が作成されます（デフォルトは0です）
MAXACTIVE：接続プール内の最大接続数は、同時に（与えられた独自のアプリケーションシナリオに応じて）接続することができます
maxIdle：接続プールのアイドル状態の内の最大接続数を超えます負の値が制限されていない場合、アイドル状態の接続（デフォルトは8で、maxIdleは、あまりにも小さく設定されていない、リリースされる予定
であればより高速な接続の終了時間よりも高負荷、開放時間の場合には、接続プールが原因となりますので、番号はXmxのセットのJVMパラメータと同様頻繁接続破壊および作成、）原因、アイドルmaxIdle以上増加し
、新しい接続を作成するよりも、接続プールの空きが、この数は低くなる接続の最小数（デフォルト：minIdleを0は、5に調整し、このパラメータが近いmaxIdle、優れたパフォーマンスで、
接続が作成され、破壊され、リソースを消費するために、すべての必要されているので、マシンがアイドル状態にあるので、あまりないけど、小さいminidleより作成されます。接続の数、同様のXMNは、JVMパラメータを提供）
MAXWAIT：最大待機時間、利用可能な接続がない、接続 時間制限は例外がスローされます超え、時間接続解放を待っている最大値は、
あなたが設定されている場合は-1無限に待機することを示している（スレッドプールを避けるために、60000msに調整デフォルトは無制限です、十分ではありません、要求につながった無制限保留されている）
poolPreparedStatementsを：オープンプールが用意します（デフォルトは試験後、良いターン後のパフォーマンスが閉じられていない、偽の未調整である。）
maxOpenPreparedStatements：プールが準備した後、同時接続の最大数を開く（デフォルトでは無制限、上記のように、構成されていません）
minEvictableIdleTimeMillis：接続プールされた接続が、それは、時間が接続プールから追放されたアイドル期間となっている
（デフォルトは、適切な調整、ニーズやポリシー設定のバックエンドサーバー関連を作ることができ、30分）
removeAbandonedTimeoutを：制限を超えた時は、回復なし（捨てられた）接続して（デフォルトは300秒である、[180に調整した）が
removeAbandoned：後よりremoveAbandonedTimeoutを時間よりも、無用の接続は（廃棄物）を回収するかどうか（デフォルトはfalse、trueに調整し
た場合オープンタイムアウト機構はこのプール中に回収することができる場合に、接続を考慮し、 "removeAbandoned"（getNumIdle（）<2）及び （getNumActive（）> - 。 トリガされたときgetMaxActive（）3）。
例：= 20 MAXACTIVE、18のアクティブな接続、アイドル接続は「removeAbandoned」1が、一度にアクティブな接続がよりだけ削除する「removeAbandonedTimeoutを」、結果セットのデフォルト300秒の旅行より使用されていないをトリガすることができ使用されているようにカウントされません。
logAbandoned = trueの場合、それは、イベントの後に回復する忘却に関連してデバッグするときに非常に便利な、閉じた場合を含む、ログにエラーメッセージ接続の回復をプリントアウトします。
----------------
免責事項：この記事はCSDNブロガー「jacky_2015の元記事である、CC 4.0 BY-SAの著作権契約書に従ってください、複製、元のソースのリンクと、この文を添付してください。 。
オリジナルリンクします。https：//blog.csdn.net/jacky_2015/java/article/details/53064037