posts - 42,comments - 83,trackbacks - 0
        在网络性能较差的环境中,weblogic server的日志中经常能看到如下的两种异常,

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}

        BEA-101326通常跟网络性能有关系(60秒内,4k的数据无法发送完成),首要解决方法就是调优网络。从weblogic方面来看,我们可以通过调整如下两个参数来解决这个问题,但这不是解决问题的关键。
1:增加HttpCompleteMessageTimeout,最大值为480秒
2:减小weblogic.ChunkSize

        至于BEA-101083,通常是因为客户端发送的请求数据不能在HttpCompleteMessageTimeout内完成,常见的两种情况是:性能很差的网络环境、黑客攻击(连续的向服务器写入数据,但每次写入很少的数据,例如,10bytes/secs或更少)。客户端数据读取超时是通过SocketMuxer.TimeoutTrigger实现的。这个trigger同时还负责IdleTimeout(KeepAlive的HttpConnection的Duration,默认为30秒)。

 1   /*package*/ final int checkTimeout(long idleTimeout, long msgTimeout) {
 2     int status = OKAY;
 3     long interval;
 4     synchronized (this) {
 5       
 6       if (messagePending()) {
 7         if (msgTimeout <= 0return OKAY;
 8         /*
 9         *get time left for reading message from client. When SocketMuxer begins reading packets 
10         *from http connection. System.currentTimeMills() is recorded info SocketInfo as lastMessageReadingStartedTimeMillis
11         *and in getMessageIntervalMillis(), it returns (System.currentTimeMills() - info.lastMessageReadingStartedTimeMillis)
12         *If reading finishes in time, SocketMuxer will set messagePending to false.
13         */ 
14         interval = getMessageIntervalMillis(msgTimeout);
15         if (interval <= msgTimeout) return OKAY;        
16         status = MSG_TIMEOUT;
17       } else {
18            //idle timeout is checked here
19       }
20       //for MuxableSocketHttp, ms.requestTimeout() is always true, i.e., timeout affects such connection
21       if (!ms.requestTimeout()) return OKAY;
22       setCloseOnly();
23     }
24     return status;
25   }

        对于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,
 1   protected class TimeoutTrigger implements Triggerable {
 2     public void trigger(Schedulable sched) {
 3       MuxableSocket[] socks = getSockets();
 4       for (int i = 0; i < socks.length; i++) {
 5 
 6         MuxableSocket ms = socks[i];
 7         SocketInfo info = ms.getSocketInfo();
 8         if (info == nullcontinue;
 9         long idleTimeout = ms.getIdleTimeoutMillis();
10         long msgTimeout = ms.getCompleteMessageTimeoutMillis();
11 
12         switch (info.checkTimeout(idleTimeout, msgTimeout)) {
13         
14         }
15     
16       }  
17     } 
18   }

BEA-101326, ChunkUtils
1     static {
2       trigger = new CompleteMessageTimeoutTrigger();
3     }

        从上面代码可以看出,BEA-101083的trigger每次被触发的时候,都会重新读取配置参数,所以修改是动态的。而BEA-101326,tigger是静态变量,当ChunkUtils被load的时候实例化,实例化的时候,它会读取配置参数。但静态变量的初始化只有一次,除非ChunkUtils被重新装载,所以需要重启才能使该设定生效。




posted on 2008-12-12 09:55 走走停停又三年 阅读(5386) 评论(2)  编辑  收藏 所属分类: Weblogic

FeedBack:
# re: Weblogic81中HttpCompleteMessageTimeout相关的两个异常[未登录]
2008-12-12 09:35 | xZeus
不错  回复  更多评论
  
# re: Weblogic81中HttpCompleteMessageTimeout相关的两个异常
2008-12-22 11:31 | 激情聊天室
支持  回复  更多评论