一、“Stuck Thread Max Time”和“Max Stuck Thread Time”的區別
首先說一下這兩個區別：
兩個與Stuck Threads時間配置相關的參數.一個在：服務器 – > Some_Server – >配置 – >調整具有以下參數：Stuck Thread Max Time；
其他在：服務器 – > Some_Server – >配置 – > Overload具有以下參數：Max Stuck Thread Time；
調整=卡住線程報告
Servers -> Some_Server -> Configuration -> Tuning -> Stuck Thread Max Time
這將檢查任何和所有卡住的線程的Stuck Thread Timer Interval並將其報告給服務器的日志文件,如：’WebLogic.kernel.Default(self-tuning)’一直忙於“zzz”秒工作請求“——”,這比“600”秒的配置時間(StuckThreadMaxTime)多.
過載=卡住線程反應
Servers -> Some_Server -> Configuration -> Overload -> Max Stuck Thread Time
Max Stuck Thread Time指定服務器認為線程卡住的時間長度.如果總計Stuck Thread Count線程卡住,則服務器將自身轉換為失敗狀態.一旦服務器轉換為失敗狀態. “過載”選項卡上的“失敗操作”控制要采取的糾正錯誤的操作.
二、Stuck Thread Max Time
在WEBLOGIC中如果一個線程執行時間超過了Stuck Thread Max Time規定的時間，
WEBLOGIC會把它認為是STUCK線程,並記錄在日志中。
我們也可以通過'Dump Thread Stacks' 來捕獲STUCK狀態的進程。
Home > Summary of Servers > AdminServer>Monitoring>Performance>'Dump Thread Stacks'
但並不是每次'Dump Thread Stacks' 都能捕獲Stuck狀態的進程。
只有在線程執行時間超過了Stuck Thread Max Time規定的時間
我們才有可能通過'Dump Thread Stacks' 或WEBLOGIC的日志捕獲它。
通常我們通過'Dump Thread Stacks'能捕獲到以下信息。
"[STUCK] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'" RUNNABLE native
jrockit.net.SocketNativeIO.readBytesPinned(Native Method)
jrockit.net.SocketNativeIO.socketRead(SocketNativeIO.java:32)
java.net.SocketInputStream.socketRead0(SocketInputStream.java)
java.net.SocketInputStream.read(SocketInputStream.java:129)
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
java.io.BufferedInputStream.read(BufferedInputStream.java:313)
com.informix.asf.IfxDataInputStream.readFully(IfxDataInputStream.java:146)
com.informix.asf.IfxDataInputStream.readSmallInt(IfxDataInputStream.java:453)
在WEBLOGIC的日志中我們能看到如下信息：
<2020-07-08 下午02時38分28秒 CST> <Error> <WebLogicServer> <BEA-000337> <[STUCK]
ExecuteThread: '189' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "635" seconds
working on the request "Http Request: /prpall/business/selectPolicy.do", which is more than the configured
time (StuckThreadMaxTime) of "600" seconds. Stack trace:
java.net.SocketInputStream.socketRead0(Native Method)
java.net.SocketInputStream.read(SocketInputStream.java:129)
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
java.io.BufferedInputStream.read(BufferedInputStream.java:313)
com.informix.asf.IfxDataInputStream.readFully(IfxDataInputStream.java:146)
com.informix.asf.IfxDataInputStream.readSmallInt(IfxDataInputStream.java:453)
com.informix.jdbc.IfxSqli.receiveMessage(IfxSqli.java:2495)
com.informix.jdbc.IfxSqli.a(IfxSqli.java:1752)
com.informix.jdbc.IfxSqli.executeStatementQuery(IfxSqli.java:1704)
com.informix.jdbc.IfxSqli.executeStatementQuery(IfxSqli.java:1635)
com.informix.jdbc.IfxResultSet.a(IfxResultSet.java:206)
com.informix.jdbc.IfxStatement.executeQueryImpl(IfxStatement.java:1229)
com.informix.jdbc.IfxPreparedStatement.executeQuery(IfxPreparedStatement.java:376)
weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:100)
在壓力測試階段為了捕獲執行時間長的進程我們可以調整
weblogic中的Stuck Thread Max Time 為一個較小的值。
來捕獲並發測試時stuck狀態的進程。比如30秒。
通常在產品環境中設置此參數值為600秒。
設置路徑為：Home > Summary of Servers > AdminServer >Tuning >Stuck Thread Max Time
11g的路徑：
三、出現的相關問題及處理
-
出現這個問題有程序方面、網絡方面、weblogic設置方面等等原因。
因為：
- 程序問題，需要項目自己去解決，weblogic在做優化處理也於事無補。
- 網絡中斷或者認為關閉交互這種情況也不能用weblogic處理（這點我是這么認為的）
說明：
,"weblogic.kernel.Default"是從客戶端提交請求后產生的線程所在的隊列名。這個隊列的線程數默認是15個。如果超過15個線程堵塞，則部署的應用將不能訪問。同時后台報：
<XXXX-XX-XX 下午XX時XX分XX秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteThread: '14' for queue: 'weblogic.kernel.Default' has been busy for "1,720" seconds working on the request "Http Request: /myapp/test/index.jsp", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.>
線程數(Tread Count)：指派到weblogic.kernel.Default隊列的線程數。如果你不需要使用超過15個線程（默認），就不必更改這個屬性值。
2.解決方法
如果發送該請求較多，很有可能會導致weblogic的線程阻塞，嚴重會引起weblogic掛起現象。
可以通過以下幾種方法解決：
1）修改StuckThreadMaxTime參數，將默認的600s改成1200s，或者其它適合的值。（路徑見截圖）
2）增大線程數，防止線程阻塞問題。
3）優化程序，減少處理時間。