Seems to me that the application shouldn't handle the failure because it is pretty much a fatal error. The framework operator needs to do something while the apps are blocked, the failure would affect all loaded applications. Once the framework gives up, there is no more recovery, stream queues will fill up and block, and the whole system will stop until the operator resolves the problem. Is there any other possible scenario? What can an app do once it is informed other than log more errors?
-leo On Fri, Nov 11, 2011 at 11:52 AM, Karthik Kambatla <[email protected]>wrote: > Yes, we have to retry connecting to the node but only a bounded number of > times, after which we give up. If someone decides to use TCP, it is for > guaranteed message delivery in which case the application needs to be > informed. > > What we need to decide is whether to let the application handle an > exception or a return value? > > Karthik > > On Fri, Nov 11, 2011 at 2:41 PM, Leo Neumeyer <[email protected]> > wrote: > > > Presumably the scenario is that we will retry so I guess we should log > each > > connection error when the exception is thrown. > > > > What can we do if we were to return false? We can always do this later > once > > we decide how to handle the error, no? > > > > -leo > > > > On Fri, Nov 11, 2011 at 11:25 AM, Karthik Kambatla > > <[email protected]>wrote: > > > > > How should we go about handling connection failures (not being able to > > > connect to) for a send(). > > > > > > We can either (1) throw java.net.ConnectException or (2) return false. > In > > > the second case, we need to modify the Emitter.send to return boolean. > > > Comments? > > > > > > Thanks > > > Karthik > > > > > > > > > > > -- > > > > Leo Neumeyer (@leoneu) > > > -- Leo Neumeyer (@leoneu)
