Loading ...关于
我的项目
相关阅读
热度排行
- [转] 宫崎骏用动漫教给我们的人生哲理，每一句都能说到心里！ - (日期:[八月 24, 2013] 点击:[53,219])
- Google 网页爬虫报告无法连接站点解决办法 - (日期:[七月 20, 2014] 点击:[38,641])
- 架设Tiny Tiny RSS（TTRSS）阅读器，找回Google Reader！ - (日期:[九月 27, 2013] 点击:[27,768])
- SkyDrive、DropBox和Google Drive三大公有云存储服务对比 - (日期:[六月 25, 2013] 点击:[25,573])
- 升级到至强E5440后，与i5 CPU笔记本性能对比 - (日期:[二月 18, 2014] 点击:[23,713])
- 公钥私钥加密解密数字证书数字签名详解 - (日期:[四月 19, 2014] 点击:[22,959])
- 本站建站技术合集 - (日期:[九月 20, 2013] 点击:[22,490])
- 使用OpenerDNS解决无法访问Google的问题 - (日期:[七月 5, 2014] 点击:[21,789])
- WordPress博客添加“返回顶部”按钮 - (日期:[七月 14, 2013] 点击:[21,203])
- Linux文件系统基础之inode和dentry - (日期:[三月 13, 2015] 点击:[20,167])
- 云存储中的HTTP鉴权算法分析 - (日期:[二月 7, 2014] 点击:[18,639])
- 存储基础知识之——磁盘阵列原理及操作实战 - (日期:[二月 9, 2014] 点击:[17,491])
- 精选37条强大的常用linux shell命令组合 - (日期:[九月 4, 2013] 点击:[17,428])
- DNS原理、架构和配置详解 - (日期:[九月 6, 2013] 点击:[16,802])
- Netty和Jetty的Java NIO 网络框架模型分析 - (日期:[七月 13, 2013] 点击:[16,333])
- CoreOS 初识之安装 - (日期:[十一月 16, 2014] 点击:[16,170])
- Windows与Linux文件系统互访的几种方法 - (日期:[八月 21, 2014] 点击:[15,733])
- Dijkstra算法求解最短路径分析 - (日期:[七月 12, 2014] 点击:[14,924])
- NAS解决方案实现多媒体文件共享播放 - (日期:[十二月 21, 2014] 点击:[13,915])
- 简介 - (日期:[九月 1, 2012] 点击:[13,757])
- 如何编程实现 2 + 2 = 5？ - (日期:[六月 2, 2014] 点击:[13,269])
- 搭建了一个iNews程序 - (日期:[十月 15, 2013] 点击:[13,236])
- 2014年9月曝出的Bash ShellShock漏洞简析 - (日期:[九月 26, 2014] 点击:[13,138])
- 彻底解决WordPress博客垃圾评论的问题 - (日期:[八月 5, 2013] 点击:[13,086])
- 如何使用1M的内存排序100万个8位数 - (日期:[三月 27, 2014] 点击:[12,552])
- 全部日志列表 - (日期:[十一月 11, 2012] 点击:[12,328])
- 关于回调函数和this指针探讨 - (日期:[八月 24, 2014] 点击:[12,209])
- 给定一个long型常量，其值为x，给定long型变量a，要求a & x 的取值集合 - (日期:[九月 8, 2012] 点击:[11,703])
- WordPress建站必备实用插件 - (日期:[八月 7, 2014] 点击:[11,360])
- Amazon 云计算业务全面介绍 - (日期:[三月 9, 2014] 点击:[11,268])
分类目录
文章归档
- 2024年四月 (1)
- 2024年二月 (1)
- 2023年九月 (1)
- 2023年一月 (1)
- 2022年十月 (1)
- 2022年八月 (2)
- 2022年四月 (1)
- 2022年三月 (1)
- 2021年十二月 (2)
- 2021年十月 (2)
- 2021年九月 (1)
- 2021年八月 (1)
- 2021年五月 (1)
- 2021年三月 (2)
- 2021年一月 (2)
- 2020年十二月 (5)
- 2020年十一月 (2)
- 2020年十月 (2)
- 2020年九月 (1)
- 2020年八月 (5)
- 2020年七月 (2)
- 2019年九月 (1)
- 2018年八月 (1)
- 2018年七月 (1)
- 2018年六月 (1)
- 2018年五月 (1)
- 2018年三月 (1)
- 2018年二月 (1)
- 2018年一月 (2)
- 2017年十二月 (3)
- 2017年十月 (4)
- 2017年九月 (1)
- 2017年七月 (1)
- 2017年六月 (1)
- 2016年十二月 (1)
- 2016年十月 (1)
- 2016年九月 (1)
- 2016年七月 (2)
- 2016年六月 (1)
- 2016年二月 (3)
- 2015年十二月 (3)
- 2015年十一月 (2)
- 2015年十月 (1)
- 2015年八月 (2)
- 2015年七月 (4)
- 2015年六月 (1)
- 2015年三月 (2)
- 2015年二月 (1)
- 2015年一月 (4)
- 2014年十二月 (2)
- 2014年十一月 (2)
- 2014年十月 (5)
- 2014年九月 (8)
- 2014年八月 (11)
- 2014年七月 (17)
- 2014年六月 (7)
- 2014年五月 (15)
- 2014年四月 (16)
- 2014年三月 (14)
- 2014年二月 (5)
- 2013年十二月 (5)
- 2013年十一月 (3)
- 2013年十月 (13)
- 2013年九月 (13)
- 2013年八月 (13)
- 2013年七月 (9)
- 2013年六月 (8)
- 2013年五月 (1)
- 2013年三月 (3)
- 2013年一月 (1)
- 2012年十一月 (1)
- 2012年九月 (12)
- 2012年八月 (3)
- 2011年二月 (1)
- 2009年三月 (1)
- 2009年二月 (1)
- 2008年十一月 (1)
- 2008年六月 (1)
- 2008年四月 (1)
- 2008年三月 (1)
Jetty误判长连接为超时连接的问题
在上一篇中介绍了jetty的反映器模型，selector线程与业务子线程交互的点有：
1、分发事件给子线程做，启动子线程；
2、子线程发现阻塞或者连接关闭等时间时，注册内部changes，等待selector线程调度；
3、检测超时连接，并且关闭连接。
在检测超时连接上面，jetty存在较多的问题，可能会误判。下面是一个典型的问题，问题一步一步定位的过程也是非常艰难和曲折的，但是最终问题找到的时候却发现不过如此。
具体的问题出在下面这个判断表达式上面，下面这个方法是由主线程派生一个子线程的来调用的，在这个线程里面对所有的连接进行超时检查。
// Idle tick
if (now-_idleTick>__IDLE_TICK)
{
_idleTick=now;
final long idle_now=((_lowResourcesConnections>0 && selector.keys().size()>_lowResourcesConnections))
?(now+_maxIdleTime-_lowResourcesMaxIdleTime)
:now;
dispatch(new Runnable()
{
public void run()
{
for (SelectChannelEndPoint endp:_endPoints.keySet())
{
endp.checkIdleTimestamp(idle_now);
}
}
});
}
被调用的方法：
/* ------------------------------------------------------------ */
public void checkIdleTimestamp(long now)
{
if (_idleTimestamp!=0 && _maxIdleTime!=0 && now>(_idleTimestamp+_maxIdleTime))
{
idleExpired();
}
}
_idleTimestamp是每个连接实例中标志连接上次空闲的开始时间，如果该值为0，则说明连接处于非空闲，当子线程在处理请求时会频繁地将该变量在0值与空闲的时间点之间切换，而该变量本身是寄存器变量，可以保证变量本身在多线程之间的同步。但是上面是一个表达式，假如运行的时序是下面这样的：
1、子线程刚刚将连接置为空闲，那么_idleTimestamp大于0；
2、主线程开始判断该连接是否超时，判断到_idleTimestamp>0满足；
3、当程序继续运行时，子线程又将_idleTimestamp切换为0；
4、主线程开始判断now>(_idleTimestamp+_maxIdleTime)的条件，发现也满足；
5、最终，所有判断条件均为真，进入关闭连接的流程，连接被关闭。
这样就形成一个误判。本来连接上的请求正在处理，却被提前关闭了，最终会导致某一个请求处理失败，并且是莫名其妙的失败，网络抓包能发现是服务端关闭了连接，但是到底是谁关闭了连接都很难知道，最终通过在关闭socket的地方记录堆栈，待到堆栈累计到一定程度时，将其打印到日志中，结合抓包数据就能发现问题所在。
问题明确了，修改方法也简单：
/* ------------------------------------------------------------ */
public void checkIdleTimestamp(long now)
{
long idleTimestamp = _idleTimestamp;
if (idleTimestamp!=0 && _maxIdleTime!=0 && now>(idleTimestamp+_maxIdleTime))
{
idleExpired();
}
}
这样就避免了在计算表达试的过程中全局变量的值被改变了。问题解决。
这个问题解决之后，紧随其后，又发现了另外一个更加奇怪的现象：
发现在连接启动之后，业务已经在处理中，最终业务处理完成，但是对外回复响应时却发现连接已经被关闭了。这个问题与上面的问题很像，但是不是同一个问题。经过上面的分析定位，对这里已经有一定的积累，很快就找到了连接关闭的根源，还是在检查超时连接上面。
经过反复推敲，发现问题出在下面３个函数的配合上面，当一个连接上面接近200秒（连接最大超时时间）都没有任何请求，而此时一个新的请求已经启动，但是还没有来得及调用cancelIdle来置空闲标志为0，这时请求已经开始处理，就在这个时候，主线程开始检查连接是否超时，结果发现已经超过200秒，连接上面没有处理任何数据，走入关闭连接的流程。
而此时业务线程已经在处理数据，等待数据处理完成，需要回复响应的时候才发现此连接已经断开了。这样客户端无法收到任何讯息。服务端记录该请求失败，但实际上请求已经处理成功。
/* ------------------------------------------------------------ */
public void scheduleIdle()
{
_idleTimestamp=System.currentTimeMillis();
}
/* ------------------------------------------------------------ */
public void cancelIdle()
{
_idleTimestamp=0;
}
/* ------------------------------------------------------------ */
public void checkIdleTimestamp(long now)
{
long idleTimestamp = _idleTimestamp;
if (idleTimestamp!=0 && _maxIdleTime!=0 && now>(idleTimestamp+_maxIdleTime))
{
idleExpired();
}
}
这个问题的修改方法稍微复杂一点：
/* ------------------------------------------------------------ */
public void scheduleIdle() throws IOException
{
synchronized (idleClosing)
{
if (idleClosing.get())
{
throw new IOException("the connection was closed right now. this request will be responsed a wrong value.");
}
else
{
_idleTimestamp=System.currentTimeMillis();
}
}
}
/* ------------------------------------------------------------ */
public void cancelIdle()
{
_idleTimestamp=0;
}
/* ------------------------------------------------------------ */
public void checkIdleTimestamp(long now)
{
long idleTimestamp = _idleTimestamp;
if (idleTimestamp!=0 && _maxIdleTime!=0 && now>(idleTimestamp+_maxIdleTime))
{
synchronized (idleClosing )
{
if (_idleTimestamp == 0)
{
Log.warn("the request is doing. it cannot be closed!");
return;
}
else
{
idleClosing.set(true);
}
}
idleExpired();
}
}
在两个方法之间用一个标志量来作为同步依据，当关连接的事情先发生，那么切换状态的操作就会因为idleclosing标志已经被置而直接抛出异常，不至于子线程继续处理数据。如果是子线程置连接为非空闲在前，则主线程的关连接操作也会不关连接而直接返回。
