文章讲述了作者在使用IoTDB时遇到SessionPool操作延迟并最终未执行成功的问题。通过查看日志和源码，作者发现由于未正确关闭SessionDataSetWrapper导致SessionPool占用不降，修复这一问题后系统恢复正常。作者还提醒读者要充分利用AutoCloseable特性以避免类似问题，并指出详细阅读文档的重要性。
最近在尝试使用 IoTDB，测试下来发现性能非常好。而且原生 API 提供了 SessionPool，并发写入查询不用自己控制 Session 的连接，着实是很方便。
但是稳定运行一段时间后发现使用 SessionPool 进行操作很长时间才返回结果，而且并未执行成功。重启客户端后又恢复了。恢复后稳定运行一段时间后又出现这种问题，感觉很奇怪。随即开始进行排查。
首先SessionPool 为了更高的并发，设置了 maxSize 为 100。但还是会出现上述问题。
然后开始查看日志，发现出现操作很长时间才返回结果现象时出现了如下日志。
找到了日志，发现了一些关键信息，当前 SessionPool 中占用为 100，并且一直没有降下来。
current occupied size 100（当前占用）
queue size 0（队列）
considered size 100（初始设定）
没有其他额外的信息，然后开始看 SessionPool 的源码（开源的找起来真方便）
首先查找关键字 occupied，发现一段注释，大意是需要 closeResultSet。
继续向下看，发现了变量定义的地方，意思是 resultSet 没有 released 的会放到这里 
后面又看到了什么时候会增加，什么时候会减少
看到这里，我又回头看了看自己的代码，果然没有对 SessionDataSetWrapper 进行 close 操作，随即加上 close，稳定运行一段时间后，没有出现之前对问题了。
后面又看到 SessionDataSetWrapper 是 AutoCloseable 的，也可以用 try-resources 方式来进行 AutoCloseable。
到这里问题就解决了。后面翻了翻官方文档，发现如下介绍。
看来还是自己太年轻，没有仔细看文档😅😅😅
1061
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
