这是分析长链掉坑里源码:
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的内部实现模式上看基本就是走的一请求一应答然后再往下的意思
