2 
public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException {

        if ((request instanceof HttpServletRequest)
                && (response instanceof HttpServletResponse)) {
            HttpServletRequest httpServletRequest = (HttpServletRequest) request;
            HttpServletResponse httpServletResponse = (HttpServletResponse) response;

            if (isSessionControlRequiredForThisResource(httpServletRequest)) {

                if (isSessionInvalid(httpServletRequest)) {

                    String encodedURL = httpServletRequest.getContextPath() + this.timeoutPage;

                    try {
                        httpServletResponse.sendRedirect(encodedURL);
                    } catch (Exception e) {
                        logger.error("[Error happened in filter] : ", e.fillInStackTrace());
                    }

                    return;
                }
            }

            if (!httpServletRequest.getRequestURI().startsWith(httpServletRequest.getContextPath() + ResourceHandler.RESOURCE_IDENTIFIER)) {
                httpServletResponse.setHeader("Cache-Control", "no-cache, no-store, must-revalidate");
                httpServletResponse.setHeader("Pragma", "no-cache");                    
                httpServletResponse.setDateHeader("Expires", 0);
                }
            }
            chain.doFilter(request, response);
        }

上記のコードは、ミッション中に失敗し、 に示す次のエラーが発生することがありますSystemOut.log。

[8/26/13 8:38:39:873 MYT] 0000002c ThreadMonitor W WSVR0605W: スレッド "WebContainer : 9" (00000037) が 611221 ミリ秒間アクティブであり、ハングしている可能性があります。サーバーには、ハングしている可能性のあるスレッドが全部で 7 つあります。

このエラーの診断は簡単ではありませんでした。これは、私のアプリケーションに属さない非常に長いスタック トレースのリストが常に続くためです。通常、一定時間 (約 15 ～ 20 分) の間に数回発生する可能性がありますが、スレッド ID は異なる可能性があります。

UAT サーバーの単体テストでこれをシミュレートすることができず、この問題の根本的な原因が何であるかがわかりませんでした。それは時々起こります。このエラーをキャプチャするパターンはありますか? DB接続が失われた、またはバックグラウンドプロセスが実行されていたなど、他の例外が発生した後、本番サーバーで巨大な結果セットを取得した後に発生しますか? コーディング中にこれを回避できるように、どのような状況がこの問題につながる可能性があるかを理解しようとしています。

4

2 に答える 2

4
  • たとえば、次を使用して、WebSphere プロセスの PID を判別しますjps

$ jps
1039 ジャワ

  • を使用して完全なスレッド ダンプを作成します。jstack

$ jstack 1039

  • または (UNIX システムの場合):

$ kill -QUIT 1039

$ kill -3 1039

  • ハングしているスレッドを特定します (ログ ファイルの警告から名前を取得します)。
  • スレッドがハングする行を特定します
    • 競合状態、非並行オブジェクト/イテレーターでの並行変更などを探します。
  • デッドロックも検査します (完全なスレッド ダンプに追加される可能性があります)。
    • デッドロックの例を次に示します(状態のスレッドを探しますBLOCKED)。

関連している：

于 2013-08-26T10:08:28.787 に答える
1

このエラーの診断は簡単ではありませんでした。これは、私のアプリケーションに属さない非常に長いスタック トレースのリストが常に続くためです。

おそらく、ここでスタック トレースを共有することをお勧めします。これは、ThreadMonitor のハング スレッド メッセージ (WSVR0605W) に関連するものです。

スレッド ダンプの生成に関するベリリウムの回答 (kill -3 <pid>正常に動作します) に基づいて構築すると、IBM Thread and Monitor Analyzerツールを使用して、生成されたスレッド ダンプ ファイルを表示できます。ツールはスレッドの状態を表示します。名前が「Web Container:」で始まるブロックされたスレッドを探し、モニターやその他のスレッドに関する手がかりがあるかどうかを確認します。kill -3 <pid>実際、一度実行し、約 15 ～ 30 秒待ってから再度実行することをお勧めkill -3 <pid>します。Thread and Monitor Analyzerを使用すると、2 つの「差分」を表示して、実際にハングしているスレッドと、実行が遅いだけのスレッドを確認できます。また、ヒープの枯渇についても警告します。

于 2013-09-15T20:30:52.453 に答える