今天下午线上的Jetty服务又停止响应了。不过与上次不同的是，日志里没有Too many open files的问题（看来ulimit设置管用了），看不出任何问题。于是用netstat检查网络连接，发现了大量CLOSE_WAIT状态的连接，而且都是连接到同一个IP地址。联想到程序里有调用外部网站服务的部分，检查这个IP，正是其中的一个服务。检查代码，发现开发人员使用Commons HttpClient时出了问题，居然忘记关闭连接了(method.releaseConnection();)！！后果就是对方关闭了连接，连接不断地变成CLOSE_WAIT状态，直到耗尽所有的网络资源，没法再建立连接了。
从这个教训看出，项目的研发管理真是没有到位啊！快速反复的需求、几乎可以忽略的设计、缺少代码走查、没有单元测试，怎能保证上线前发现这样的问题！
今天下午，线上的Jetty服务宕机了，日志里大量的"java.io.IOException: Too many open files"错误。搜索到Freddy Chu的博客里正好有关于此的解决办法。
$ sysctl fs.file-max
$ lsof -u jetty -nn | wc -l
$ ulimit -a
$ sudo vi /etc/security/limits.conf
* soft nofile 65535
* hard nofile 65535
同时发现了系统里也有Freddy Chu提到的"Too many CLOSE_WAIT"问题，谢谢Freddy Chu。
$ sudo vi /etc/sysctl.conf
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_intvl = 2
net.ipv4.tcp_keepalive_probes = 2
net.ipv4.tcp_keepalive_time = 1800
$ sudo sysctl -p
Update(2010-01-21): root用户要特殊设置
$ sudo vi /etc/security/limits.conf
root soft nofile 65535
root hard nofile 65535
使用Maven进行Java的web开发，Jetty Plugin是必不可缺的插件，可以极大的提到开发效率。但在Windows环境下会遇到静态文件（html、css、js）被锁定、无法即时更新的问题。要想更新这些文件，只能先停掉Jetty，保存修改，再启动Jetty，非常不方便。
解决办法是这样的：
1、从jetty.jar中解出webdefault.xml（位于org.mortbay.jetty.webapp包下）这个文件，把这个useFileMappedBuffer参数设为false
2、把修改后的webdefault.xml文件跟pom.xml放在一起
3、修改pom.xml里的Jetty Plugin的配置，加入
...
...
...