这是分析长链掉坑里源码:
accept之后只注册了read

这个不是最重点,看看读吧,这是重点
org.apache.thrift.server.AbstractNonblockingServer.FrameBuffer#read

基本是正常读了一个Frame后就不读了,就是不关注读的事了
重点来了,什么时候再开始呢?
我们来看下写

需要判断 buffer的状态的时候才会去注册写事件
继续看这个buffer的状态
org.apache.thrift.server.AbstractNonblockingServer.FrameBuffer#responseReady

再看看写buffer,这就知道整个的模式了吧,整理如下
1 客户端先发一个Req
2 server端在对这个发Req的链接已经注册了读事件
3 server收到这一个完整的Req,不管还有没有其它的req,先不继续管read事件了
4 server端处理完后,改写buffer的状态,并注册了写事件
5 server端写回去,这才再开始下一轮...
结论是对一个长链接,压根是不可复用的...至少
TThreadedSelectorServer的内部实现模式上看基本就是走的一请求一应答然后再往下的意思
本文深入探讨了Apache Thrift的TThreadedSelectorServer在处理长链路通信时的机制,揭示了一请求一应答模式下,服务器如何通过读写事件的注册与取消,实现对长链接的有效利用。分析表明,该模式下长链接并非完全复用,而是每次请求后重新等待下一次请求。
712

被折叠的 条评论
为什么被折叠?



