Jetty 8 长连接的超时断开连接的机制:超时连接机制针对IO传输过程中的数据阻塞时间超过一定阈值时,断开该连接。阻塞指当前处于数据传输阶段,但是连续指定时间内都没有发出或者接收到任何数据时,Jetty系统断开该连接。强调一下,只有在数据传输过程中才会有超时机制。在服务端处理已经收到的数据时是不会检测该超时时间的。
下面看一下具体的代码实现。在jetty 8.1.17版本中,由以下代码控制一个连接的空闲、非空闲和断开检查方法,在SelectChannelEndpoint类中:
Jetty 8 长连接的超时断开连接的机制:超时连接机制针对IO传输过程中的数据阻塞时间超过一定阈值时,断开该连接。阻塞指当前处于数据传输阶段,但是连续指定时间内都没有发出或者接收到任何数据时,Jetty系统断开该连接。强调一下,只有在数据传输过程中才会有超时机制。在服务端处理已经收到的数据时是不会检测该超时时间的。
下面看一下具体的代码实现。在jetty 8.1.17版本中,由以下代码控制一个连接的空闲、非空闲和断开检查方法,在SelectChannelEndpoint类中:
这个问题很早就分析、修改和验证过了,一直没有来得及总结整理。今天突然想起来了,首先用我那蹩脚的英语给jetty的维护团队提了一个问题单,在等待他们回复的同时,我也把我发现问题的过程分享一下。
问题单链接:https://bugs.eclipse.org/bugs/show_bug.cgi?id=415282
经过打断点和调试,发现如下调用占用了性能下降(相对于jetty7版本)的绝大多数处理耗时:
public class HttpOutput extends ServletOutputStream
{
/* ------------------------------------------------------------ */
private void write(Buffer buffer) throws IOException
{
if (_closed)
throw new IOException("Closed");
if (!_generator.isOpen())
throw new EofException();
// Block until we can add _content.
while (_generator.isBufferFull())
{
_generator.blockForOutput(getMaxIdleTime());
if (_closed)
throw new IOException("Closed");
if (!_generator.isOpen())
throw new EofException();
}
// Add the _content
_generator.addContent(buffer, Generator.MORE);
// Have to flush and complete headers?
if (_generator.isAllContentWritten())
{
flush();
close();
}
else if (_generator.isBufferFull())
_connection.commitResponse(Generator.MORE);
// Block until our buffer is free
while (buffer.length() > 0 && _generator.isOpen())
{
_generator.blockForOutput(getMaxIdleTime());
}
}
}
public class HttpGenerator extends AbstractGenerator
{
public void addContent(Buffer content, boolean last) throws IOException
{
if (_noContent)
throw new IllegalStateException("NO CONTENT");
if (_last || _state==STATE_END)
{
LOG.warn("Ignoring extra content {}",content);
content.clear();
return;
}
_last = last;
// Handle any unfinished business?
if (_content!=null && _content.length()>0 || _bufferChunked)
{
if (_endp.isOutputShutdown())
throw new EofException();
flushBuffer();
if (_content != null && _content.length()>0)
{
if (_bufferChunked)
{
Buffer nc=_buffers.getBuffer(_content.length()+CHUNK_SPACE+content.length());
nc.put(_content);
nc.put(HttpTokens.CRLF);
BufferUtil.putHexInt(nc, content.length());
nc.put(HttpTokens.CRLF);
nc.put(content);
content=nc;
}
else
{
Buffer nc=_buffers.getBuffer(_content.length()+content.length());
nc.put(_content);
nc.put(content);
content=nc;
}
}
}
_content = content;
_contentWritten += content.length();
// Handle the _content
if (_head)
{
content.clear();
_content=null;
}
else if (_endp != null && (_buffer==null || _buffer.length()==0) && _content.length() > 0 && (_last || isCommitted() && _content.length()>1024))
{
_bypass = true;
}
else if (!_bufferChunked)
{
// Yes - so we better check we have a buffer
if (_buffer == null)
_buffer = _buffers.getBuffer();
// Copy _content to buffer;
int len=_buffer.put(_content);
_content.skip(len);
if (_content.length() == 0)
_content = null;
}
}
}
// Handle the _content
if (_head)
{
content.clear();
_content=null;
}
else if (_endp != null && (_buffer==null || _buffer.length()==0) && _content.length() > 0 && (_last || isCommitted() && _content.length()>1024))
{
_bypass = true;
}
else if (!_bufferChunked)
{
// Yes - so we better check we have a buffer
if (_buffer == null)
_buffer = _buffers.getBuffer();
// Copy _content to buffer;
int len=_buffer.put(_content);
_content.skip(len);
if (_content.length() == 0)
_content = null;
}
Netty的NIO框架模型。在以前的文章中,为解决Jetty的问题,分析过Java NIO基于多路事件分离器的异步IO框架模型。一直都没有系统分析Netty和Jetty的网络模型,这两天将二者的网络框架部分的代码仔细读了一下,整理了二者的网络模型,画出了Netty的模型图:
在图中,每个侦听都会创建一个Acceptor Reactor,由Boss线程来监控多路分离器,这里只关注连接事件,当有新的建立连接请求达到时,该线程会第一时间响应,将接收到的请求注册到事件多路分离器中,事件多路分离器有多个,默认情况下其个数为CPU核心数的两倍,应该是CPU超线程的数目。这里会给每一个达到的连接编一个序号,将序号对分离器个数取模(hash到0~3的一维空间),根据模值分配给相应的分离器。事件分离器开始监听新的连接上面的读写事件。检查线程为NioWorker。读写数据会通过回调用户注册的handler的相应接口来实现。因此,处理耗时数据的情况下,需要用户将其提交给后台线程,而不应该阻塞事件分离器,否则会导致新的连接无法建立,其他并发请求无法处理。
Jetty在代码风格上面跟Netty差别很大,看jetty代码感觉更清晰一点,可能是因为以前处理问题已经看得非常多了。前面的文章也说过,Jetty是在一个线程中调用一个同步的accept()方法来等待新的连接请求,等到新的连接到来时,就生成新的change事件放到多路分离器中,同样也是有多个多路分离器,选取原则与Netty完全一样。简单的轮询实现负载均衡。这是典型的半同步半异步(Half-Sync/Half-Async)的模式。在只使用1个事件分离器时,会发现分发线程通常会引入很多问题。前面两篇文章中提到的问题分析都跟这个有关。
不知道Jetty与Netty为什么在接受新请求这里有差别,难道Netty的方式更利于处理短连接,而Jetty则更利于处理长连接,比如Http连接?优待进一步的并发测试才能说明问题。如果netty的方式很好,那么Jetty应该也早就改成了该方式。
在上一篇中介绍了jetty的反映器模型,selector线程与业务子线程交互的点有:
1、分发事件给子线程做,启动子线程;
2、子线程发现阻塞或者连接关闭等时间时,注册内部changes,等待selector线程调度;
3、检测超时连接,并且关闭连接。
以下分析针对jetty的特定版本:http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/jetty/tags/jetty-7.2.1.v20101111
首先介绍一下Jetty的反映器模型,Jetty用的经典的NIO异步模型(Scalable IO in Java http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf)。连接管理的示意图如下:
Jetty在使用这个模型的时候,做了一些改动,acceptor是独立出来的一个阻塞线程,用于阻塞地接受新的连接请求,而所有的连接建立之后,都会想selector线程注册网络事件和内部的事件(changes),selector需要同时处理网络事件和内部的changes。同时还要定期检查超时的链接。