升级jetty-client解决Too many open files问题

问题背景

生产环境的采集经过一段时间就会报错 Too many open files，导致接下来的采集都会失败，已经严重影响到生产业务，于是抽空对此问题进行排查。

排查

看到日志报错的第一感觉是采集脚本每次都会去打开conf/application.properties文件，导致文件句柄占满没有被释放。于是先去排查定时调度的sdk源码，发现访问conf/application.properties文件的地方都会关流。

既然访问conf/application.properties文件的地方都会关流，就将注意力放在采集业务逻辑上，有可能是业务采集文件时候没有关流，导致文件句柄占满，进而导致访问conf/application.properties文件报错。

观察业务代码，采集中用到文件流的对象都放在try()中，代码执行完毕会自动关流，此处没有找到可疑点。但是业务中除了下载文件会打开文件流外，就只有保存文件时候会打开文件流。但是业务中保存文件是常用的sdk封装方法，其他系统业务也会用到，不可能会是这个地方有问题呀～

于是又再次去过一遍采集代码逻辑，排查是否有没关流的地方。排查未果。

让运维使用lsof -p PID命令观察正式环境采集程序打开文件句柄情况，得到大量以下日志。（具体可参考文章最后面的lsof拓展说明）

COMMAND     PID USER   FD      TYPE             DEVICE  SIZE/OFF       NODE NAME
java    2686219 root *455r      REG               0,49    207988 3442057181 /opt/file1.txt
java    2686219 root *456r      REG               0,49    149821 3442057183 /opt/file2.txt

从日志分析可以看到FD（文件描述符）中的值为r，说明采集文件处于被打开并处于只读模式。
而采集中唯一读文件的地方为保存文件的sdk方法。至此，排查方向改为研究sdk保存文件的方法。

原因

以下为文件保存方法的伪代码

import org.eclipse.jetty.client.util.MultiPartContentProvider;
import org.eclipse.jetty.client.util.PathContentProvider;
import org.eclipse.jetty.client.util.StringContentProvider;

@Override
	public CompletableFuture<Boolean> uploadAsync(String tableName, List<FileEntry> entryList) throws Exception {
		HttpRequest request = HttpUtils.newRequest("POST", url).timeout(timeoutInMills, TimeUnit.MILLISECONDS).header(HEADER_TOKEN_NAME, token);
		
		MultiPartContentProvider multiPart = new MultiPartContentProvider();
		for(FileEntry fileEntry : entryList) {
			
			String filePath = fileEntry.getLocalPath();
			File sourceFile = new File(filePath);
			String remotepath = fileEntry.getRemotePath();
			Map<String, Object> properties = fileEntry.getEntry().getProperties()==null? new HashMap<String, Object>() : fileEntry.getEntry().getProperties();
			properties.put(FILE_PATH, remotepath);
			
			multiPart.addFieldPart(ENTRY_NAME, new StringContentProvider(JsonUtils.obj2str(fileEntry.getEntry(), false)), null);
			multiPart.addFilePart(FILE_NAME, sourceFile.getName(), new PathContentProvider(Paths.get(filePath)), null);
		}
		
		multiPart.close();
		request.body(multiPart, null);
		.......
		}

其中multiPart.addFilePart()方法会打开文件，此处使用到了jetty-client进行文件读。
遇事不决问google，找到了一个类似没关句柄的issue：https://github.com/jetty/jetty.project/issues/3512
大致意思是jetty-client-v9.4.25之前的MultiPartIterator在遍历读文件时，content.iterator() 一直返回新的Iterator 对象。遍历后并没有将MultiPartIterator.iterator关闭，因此造成了文件句柄没有释放

解决

issue提及以及在jetty 9.4.25已经修复了该bug。升级jetty-client，查看源码，如下图：

可以发现升级后的jetty加上了关流代码。

测试环境升级jetty相关包，测试没有复现问题，至此问题解决。

lsof命令拓展

命令参数

-a 列出打开文件存在的进程
-c<进程名> 列出指定进程所打开的文件
-g 列出GID号进程详情
-d<文件号> 列出占用该文件号的进程
+d<目录> 列出目录下被打开的文件
+D<目录> 递归列出目录下被打开的文件
-n<目录> 列出使用NFS的文件
-i<条件> 列出符合条件的进程。（4、6、协议、:端口、 @ip ）
-p<进程号> 列出指定进程号所打开的文件
-u 列出UID号进程详情
-h 显示帮助信息
-v 显示版本信息

lsof输出各列信息的意义如下：

• COMMAND：进程的名称

• PID：进程标识符

• PPID：父进程标识符（需要指定-R参数）

• USER：进程所有者

• PGID：进程所属组

• FD：文件描述符，应用程序通过文件描述符识别该文件。如cwd、txt等:
  （1）cwd：表示current work dirctory，即：应用程序的当前工作目录，这是该应用程序启动的目录，除非它本身对这个目录进行更改
  （2）txt ：该类型的文件是程序代码，如应用程序二进制文件本身或共享库，如上列表中显示的 /sbin/init 程序
  （3）lnn：library references (AIX);
  （4）er：FD information error (see NAME column);
  （5）jld：jail directory (FreeBSD);
  （6）ltx：shared library text (code and data);
  （7）mxx ：hex memory-mapped type number xx.
  （8）m86：DOS Merge mapped file;
  （9）mem：memory-mapped file;
  （10）mmap：memory-mapped device;
  （11）pd：parent directory;
  （12）rtd：root directory;
  （13）tr：kernel trace file (OpenBSD);
  （14）v86 VP/ix mapped file;
  （15）0：表示标准输入
  （16）1：表示标准输出
  （17）2：表示标准错误
  一般在标准输出、标准错误、标准输入后还跟着文件状态模式：r、w、u等
  （1）u：表示该文件被打开并处于读取/写入模式
  （2）r：表示该文件被打开并处于只读模式
  （3）w：表示该文件被打开并处于
  （4）空格：表示该文件的状态模式为unknow，且没有锁定
  （5）-：表示该文件的状态模式为unknow，且被锁定
  同时在文件状态模式后面，还跟着相关的锁
  （1）N：for a Solaris NFS lock of unknown type;
  （2）r：for read lock on part of the file;
  （3）R：for a read lock on the entire file;
  （4）w：for a write lock on part of the file;（文件的部分写锁）
  （5）W：for a write lock on the entire file;（整个文件的写锁）
  （6）u：for a read and write lock of any length;
  （7）U：for a lock of unknown type;
  （8）x：for an SCO OpenServer Xenix lock on part of the file;
  （9）X：for an SCO OpenServer Xenix lock on the entire file;
  （10）space：if there is no lock.

• TYPE：文件类型，如DIR、REG等，常见的文件类型:

  （1）DIR：表示目录
  （2）CHR：表示字符类型
  （3）BLK：块设备类型
  （4）UNIX： UNIX 域套接字
  （5）FIFO：先进先出 (FIFO) 队列
  （6）IPv4：网际协议 (IP) 套接字

• DEVICE：指定磁盘的名称

• SIZE：文件的大小

• NODE：索引节点（文件在磁盘上的标识）

• NAME：打开文件的确切名称