Hi Yuliya - my read is that sendResponse in NIOServerCnxn is logging, then dropping, any Exceptions encountered during sendResponse. In other words it's doing best effort response. Not sure if that is "correct", but that's what it's currently doing in NIO. Surprisingly it's also hiding any IOExceptions, which is part of the method signature as defined by ServerCnxn. Some of the calling code is trying to handle IOException in some cases which is odd... I suspect it was an oversight in ZOOKEEPER-597, but I'm not sure.
Ben any insight? Patrick On Tue, Aug 30, 2016 at 5:15 PM, yuliya Feldman <yufeld...@yahoo.com.invalid > wrote: > Hello there, > We have been extensively testing Netty connection versus NIIO and there > are some issues that show up I wanted to get community response on. > In the process of testing https://issues.apache. > org/jira/browse/ZOOKEEPER-2509 fix we identified that sendResponse() > method may try to do some operations after close() was invoked - as > channel.close() in Netty is asynch. and subsequently lead to some NPE. > NPE itself is not a good thing but the problems aggravates with the fact > that propagation of NPE will lead to main processing thread exiting and at > that point ZK server becomes unresponsive - since no requests will be > processed anymore. > In NIOServerCnxn.java in sendResponse() it is catching Exception and just > logs a warning which was added as part of https://issues.apache.org/ > jira/browse/ZOOKEEPER-597 > I am trying to understand what a behavior should be in case of any > exception in sendResponse. > Any insight would be highly appreciated > Thanks,Yuliya > >
