Request使用proxy导致的socket连接数泄漏问题

这是一篇快餐文章,源于前天接到了服务器预警邮件,提示:连接数超过阀值。

快速定位问题,发现是因为之前跑的一个nodejs开发的小程序,该程序用于定时去指定网站采集相关数据的。

由于要采集的网站需要设置翻墙代理,很麻烦的。之前直接使用Request来发http请求也没碰到这个问题。所以归结为是由于使用proxy不稳定,导致大量的socket异常。

在进入主题之前,先吐槽一下 Request 这个库,它的文档看似详实,但如果你仔细阅读就会发现很简陋。很多地方感觉欲言又止,很是让人烦躁。

尝试去看它的源码,发现它返回异常的方式采用了2种不同的方法:

  • 沿用nodejs的回调返回异常风格
  • 发布异常事件

这也是一开始总是被无法捕获的异常导致程序crash的原因。

github上的issues翻到别人的异常捕获异常方法,也是醉了:

Request
.get({/*some config*/}, function(err, response){/*回调逻辑,第一个参数为error*/})
.on('error', function(error){
  // 再次绑定error事件
  console.error('Request on error');
  console.error(error.stack);
});

不晓得这是要闹哪样。不过经过绑定了这个error事件后,发现几乎Request触发的所有异常都被其捕获到了。至少确实管用,不会再因为无法捕获的异常而导致程序crash了(还存在一些异常,我建议 process.on('uncaughtException') 还是不能省)。

接下来主题,先看一下一个 issue ,题主已经详细描述了问题也给了解决方案。

实测了一天,感觉确实解决了,至少从图标中观测正常许多了:

Request使用proxy导致的socket连接数泄漏问题

如果去看源码,会发现很绕,毕竟到处可见的回调和事件流。不过从解决方案上来看, 很直观 。思路就是在: 确保在链接出现异常后也触发回调,在回调中来处理善后工作,最终会回收相关资源,而不是直接清除掉必要的事件监听器

去看源码吧,你将会收获更多。

原文 

http://blog.kazaff.me/2016/12/30/Request使用proxy导致的socket连接数泄漏问题/

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » Request使用proxy导致的socket连接数泄漏问题

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址