我们为什么不采用ning的AsyncHttpClient

坦白的说,现在的量没有到非要用高性能异步httpclient的时候,用jdk自身提供的URLConnection足够了,最多为便捷性封装一下。真要考虑性能的话还有其他的解决方案未必一定要选择AsyncHttpClient。它依赖了netty已经不那么轻巧;另外去年我们遇到过tomcat不能正常退出的情况,发现是由这个框架里的某个non-daemon线程引起的,当时在微博上贴过:

ning的AsyncHttpClient 里启动了一个 netty 的 HashedWheelTimer 线程,这个线程挺有意思的,本来父线程已经是 daemon 的了,但使用 jdk 的 DefaultThreadFactory 给显式的 setDaemon(false) 了,致使这个线程一直以 non-daemon 方式运行, tomcat正常的stop没法结束这个 non-daemon 线程,要kill才行

"Hashed wheel timer #3" #44 prio=5 os_prio=0 tid=0x000000000a3a5000 nid=0x1ac5 waiting on condition [0x0000000043c70000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
    at java.lang.Thread.sleep(Native Method)
    at org.jboss.netty.util.HashedWheelTimer$Worker.waitForNextTick(HashedWheelTimer.java:445)
    at org.jboss.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:364)
    at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
    at java.lang.Thread.run(Thread.java:745)

估计作者并未考虑在servlet容器里使用的情况,当时没有找到有效的方法解决,也没时间去深入了解,直接切换到JDK的URLConnection

当然我是针对我们的场景,如果你在使用AsyncHttpClient时也遇到non-daemon线程的问题,可以参考一下当时姜宁的回复(可以给AsycnClient提个patch, Netty HashedWheelTimer 的构造支持替换 ThreadFactory),对创建HashedWheelTimer的线程工厂做一下手脚。

我们为什么不采用ning的AsyncHttpClient》上有1条评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注