1：####<Mar 1, 2005 12:18:57 PM PST> <Error> <HTTP> <****> <****> <ExecuteThread: '3' for queue: 'weblogic.kernel.System'> <<WLS Kernel>> <> <BEA-101083> <Connection failure. java.io.IOException: A complete message could not be read on socket: 'weblogic.servlet.internal.MuxableSocketHTTP@115954e - idle timeout: '30000'
ms, socket timeout: '100' ms', in the configured timeout period of '60' secs
2：####<2008/11/14 09:18:23 PM PST> <Info> <HTTP> <****> <****> <ExecuteThread: '0' for queue: 'weblogic.kernel.System'> <<anonymous>> <> <BEA-101326> <The server could not send the HTTP message during the configured timeout value. The socket has been closed.>
我們可以看到上面的兩個異常都是因爲在指定的timeout時間內完成數據包的發送。BEA-101083出現在客戶端請求往服務器端發送請求數據的時間內沒有結束，而BEA-101326則是發生在weblogic回寫response的時候在指定的timeout內沒有完成數據包發送。HttpCompleteMessageTimeout默認值爲60秒，最大值爲480秒。如果沒有設定，會取server---->Protocols---->General中的CompleteMessageTimout值（general中配置適合於所有協議，包括Http, T3, IIOP等）。如果兩個都沒有設定，那麼weblogic server會將該值設定爲：CompleteMessageTimeoutTrigger. CLEANUP_TRIGGER_TIMEPERIOD_LOW=2secs。
注意：CompleteMessageTimeout是數據包，而不是整個請求的timeout時間。
對於BEA-101326，假如客戶端請求下載一個100M的文件，這100M的文件將會被分解成N多TCP/IP packets進行傳送（weblogic內部爲chunk，默認的chunk大小爲4080bytes，chunk的大小可以通過-Dweblogic. ChunkSize設定）。100M的文件即使在網絡性能很好的情況下，也很難在60秒（CompleteMessageTimout的默認值）內完成，所以這個timeout不是針對整個reponse而言的。在weblogic實現中，每次回寫數據包(Chunk)的時候，會將當前的OutputStream register到CompleteMessageTimeoutTrigger中，這樣trigger被觸發的時候，它會負責檢查這個數據報是否在指定的timeout內完成發送，如果沒有，則BEA-101326會記入到日誌中，同時會關閉到客戶端的socket，剩餘的數據將無法繼續寫入。如果數據包在timeout之前已經寫完，該OutputStream會從tigger中移除，tigger不會繼續檢查該OutputStream
1 static void writeChunks(Chunk header,Chunk c, OutputStream os, int size, boolean chunkXfer) throws IOException {
2 try {
3 trigger.register(os);
4 if (chunkXfer)
5 writeChunkTransfer(header,c, os);
6 else
7 writeChunkNoTransfer(header, c, os, size);
8 } finally {
9 trigger.unregister(os);
10 }
11}
2 try {
3 trigger.register(os);
4 if (chunkXfer)
5 writeChunkTransfer(header,c, os);
6 else
7 writeChunkNoTransfer(header, c, os, size);
8 } finally {
9 trigger.unregister(os);
10 }
11}
BEA-101326通常跟網絡性能有關係（60秒內，4k的數據無法發送完成），首要解決方法就是調優網絡。從weblogic方面來看，我們可以通過調整如下兩個參數來解決這個問題，但這不是解決問題的關鍵。
1：增加HttpCompleteMessageTimeout，最大值爲480秒
2：減小weblogic.ChunkSize
至於BEA-101083，通常是因爲客戶端發送的請求數據不能在HttpCompleteMessageTimeout內完成，常見的兩種情況是：性能很差的網絡環境、黑客攻擊（連續的向服務器寫入數據，但每次寫入很少的數據，例如，10bytes/secs或更少）。客戶端數據讀取超時是通過SocketMuxer.TimeoutTrigger實現的。這個trigger同時還負責IdleTimeout（KeepAlive的HttpConnection的Duration，默認爲30秒）。
對於IdleTimeout，可以參考SocketInfo.lastIoInitiatedTimeMillis
Last time we had some activity on socket, for enforcing idle timeout of a socket. A -1 value indicates that there is no pending IO.
用於控制keepAlive的HttpConnection空閒多長時間後將被weblogic關閉，所以空閒，是指Socket上沒有IO操作。
要解決BEA-101083，基本和BEA-101326差不多，還是要解決網絡性能問題，另外就是加強網絡安全管理，防止黑客攻擊。
最後在說一下CompleteMessageTimeout設定，weblogic admin console上提示改設定是動態的，即不需要重啓，但實際並不是這樣的。如果該設定是要解決BEA-101083，那麼它是動態的，不要重啓，而如果是要解決
BEA-101326，那麼要使設定生效，重啓是必須的。我們看一下兩個trigger就知道了，
BEA-101083，SocketMuxer,
BEA-101326, ChunkUtils