Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Auto Closed
-
0.8.2.0, 0.9.0.0, 0.10.0.0
-
None
-
None
Description
BlockingChannel currently swallows all Throwables that occur within the connect method; it appears that this behavior was introduced somewhat inadvertently by KAFKA-1041.
A BlockingChannel for which connect() failed will not give any indication to the caller that connecting failed, but the first call to send() or receive() will simply throw a ClosedChannelException. This behavior gives the impression that a connection was dropped after having successfully been set up, and hides any information about what failed when the original connection was set up.
It appears that basically all uses of BlockingChannel are implemented with the expectation that an exception will be thrown by connect() if there is an issue connecting. In short, it would make a lot more sense (and make diagnosis of issues a lot easier) if exceptions from within BlockingChannel.connect were thrown all the way up the stack.
