WebLogic HttpCompleteMessageTimeout 導致的 BEA-101083 與 BEA-101326 異常深度解析

前言

在網路品質不佳或高負載環境下，WebLogic Server 常在日誌中出現兩種與 HttpCompleteMessageTimeout 相關的異常：BEA-101083（請求讀取逾時）與 BEA-101326（回應傳送逾時）。本文從原始碼層面剖析兩者成因、觸發機制、參數調整差異，並提供實務調優建議。

異常現象對照

核心參數：HttpCompleteMessageTimeout

• 預設 60 秒，上限 480 秒。
• 若未在 HTTP 協定層設定，會繼承 Server → Protocols → General 中的 CompleteMessageTimeout（適用 T3、IIOP 等所有協定）。
• 若兩者皆未設定，WebLogic 內部會 fallback 為 CompleteMessageTimeoutTrigger.CLEANUP_TRIGGER_TIMEPERIOD_LOW = 2 秒。

關鍵觀念：此逾時針對「單一網路封包（Chunk）傳輸時間」，而非整個 HTTP Request/Response 的總時間。

BEA-101326：回應傳送逾時 深度剖析

Chunk 傳輸機制

WebLogic 將回應資料切分為多個 Chunk（預設 4080 bytes，可用 -Dweblogic.ChunkSize 調整）。每次寫入一個 Chunk 時，會將 OutputStream 註冊到 CompleteMessageTimeoutTrigger：

static void writeChunks(Chunk header, Chunk c, OutputStream os, int size, boolean chunkXfer) throws IOException {
    try {
        trigger.register(os);                    // 註冊逾時監控
        if (chunkXfer) writeChunkTransfer(...);
        else writeChunkNoTransfer(...);
    } finally {
        trigger.unregister(os);                  // 寫完移除監控
    }
}

• 若單一 Chunk 在 HttpCompleteMessageTimeout 內未寫完 → 觸發 BEA-101326，關閉 Socket，剩餘資料中斷。
• 若 Chunk 寫完 → unregister，Trigger 不再追蹤該 Stream。

常見成因與調優

1. 網路頻寬/延遲不足：4KB 封包 60 秒內無法送達 → 優先優化網路。
2. 增加 HttpCompleteMessageTimeout：最大 480 秒，緩解極端慢速網路。
3. 縮小 ChunkSize：減少單次傳輸量，降低單一 Chunk 逾時機率。

BEA-101083：請求讀取逾時 深度剖析

SocketMuxer TimeoutTrigger

Server 端由 SocketMuxer.TimeoutTrigger 定期檢查：

final int checkTimeout(long idleTimeout, long msgTimeout) {
    if (messagePending()) {
        if (msgTimeout <= 0) return OKAY;
        long interval = getMessageIntervalMillis(msgTimeout);
        if (interval <= msgTimeout) return OKAY;
        return MSG_TIMEOUT; // 觸發 BEA-101083
    }
    // idle timeout 檢查...
}

• messagePending()：正在讀取 Request 封包。
• getMessageIntervalMillis()：計算從開始讀取到現在經過的毫秒數。

兩大常見成因

1. 惡劣網路環境：Client 端封包傳送過慢。
2. 惡意攻擊（Slowloris 型）：攻擊者持續低速送資料（如 10 bytes/sec），佔用 Server 執行緒與連線資源。

IdleTimeout 與 KeepAlive

SocketInfo.lastIoInitiatedTimeMillis 記錄最後一次 Socket I/O 時間，用於控制 KeepAlive 連線空閒逾時（預設 30 秒）。

參數動態生效差異：為何 BEA-101083 即時生效、BEA-101326 需重啟？

因為 ChunkUtils 的 Trigger 是 static，JVM 載入類別時只讀取一次設定；修改 Console 設定後必須重啟 Server 才能讓新值生效。

實務建議總結

1. 優先排查網路基礎建設（頻寬、延遲、封包遺失）。
2. 若須調整逾時：
    - 解決 BEA-101083 → 動態調整即可。
    - 解決 BEA-101326 → 調整後必須重啟 WebLogic。
3. 同步檢視 IdleTimeout（KeepAlive）與 CompleteMessageTimeout 兩者關係，避免設定衝突。
4. 針對惡意慢速攻擊，建議在前端部署 WAF 或 Load Balancer 進行連線速率限制。

結語

理解 HttpCompleteMessageTimeout 作用於「單一 Chunk」而非整個 Request/Response，並掌握兩種 Trigger 的初始化差異，才能精準調優並避免「以為設定生效實際未生效」的坑。網路層面的根治永遠優於單純拉長逾時參數。