是否有診斷WebSphere中發生線程掛起的做法？

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中顯示以下錯誤。是否有診斷WebSphere中發生線程掛起的做法？

[13年8月26日8：38：39：873 MYT] 0000002c ThreadMonitorW¯¯WSVR0605W：螺紋「Web容器：9」（00000037）已活躍611221毫秒並且可以被掛起。總共有7個線程在服務器中，可能會掛起。

診斷這個錯誤並不容易，因爲這總是會跟隨一個非常長的堆棧跟蹤列表，它不屬於我的應用程序。通常它可能會在特定的時間段（大約15到20分鐘）內發生幾次，但線程ID可能不同。

我無法在UAT服務器的單元測試中模擬這個，我不確定這個問題的根本原因是什麼。它偶爾會發生。有沒有一種模式來捕捉這個錯誤？這是否發生在發生其他異常之後，說數據庫連接已經丟失，或者可能是一些後臺進程正在運行，比如說在生產服務器中檢索巨大的結果集？我只是想了解什麼情況會導致這個問題，以便在編碼時避免這種情況。

來源

2013-08-26 huahsin68

您是否手動創建線程orso？ – BalusC

沒有。我確信應用程序中沒有線程。 – huahsin68

確定您的WebSphere進程的PID，例如，通過使用jps

$ JPS
1039 java的

通過創建一個完整的線程轉儲jstack

$ jstack 1039

或者（如果你是在UNIX系統上）：

$殺-QUIT 1039

$殺 - 3 1039

或使用WAS admin console

確定哪些掛起線程（S）（您從日誌文件中警告獲得的名稱）
標識線，其中線程掛起
- 尋找競爭條件，併發修改非併發對象/迭代器等。
檢查死鎖以及（它們可能附加到全螺紋轉儲）
- 一個例子並死鎖是here（尋找在狀態BLOCKED線程）。

相關：

JVM thread dump location

來源

2013-08-26 10:08:28 Beryllium

這是不容易的診斷這個錯誤，因爲這將總是一個很長的堆棧跟蹤的列表，它是遵循不屬於我的申請。

您可能希望在此共享堆棧跟蹤 - 一個與ThreadMonitor掛起的線程消息（WSVR0605W）關聯。

建立在鈹的生成線程轉儲的答案上（kill -3 <pid>正常工作），可以使用IBM Thread and Monitor Analyzer工具查看生成的線程轉儲文件。該工具將顯示線程狀態 - 您需要查找名稱以「Web Container：」開頭的阻止線程，並查看是否有任何與監視器和其他線程有關的線索。實際上，我建議一次運行kill -3 <pid>，等待大約15-30秒，然後再運行kill -3 <pid>。 Thread and Monitor Analyzer將允許您查看兩者的「差異」，以查看真正掛起的線程與可能正在緩慢運行的線程。它還會提醒你任何堆耗盡。

來源

2013-09-15 20:30:52

是否有診斷WebSphere中發生線程掛起的做法？

回答

相關問題