when the client calls send we simply add to the buffer right we do the actual send in another thread. That means we can't really know when the client calls send if we will be able to send it or not.
Its probably not a good idea to throw exception in the thread which is doing the actual send instead we can have a retry buffer per destination and put the failed message into that buffer. Obviously this buffer must be limited and we can provide a support to get notified if this buffer fills up. Once we get notified that any buffer is full we can return false. What i am trying to accomplish is - A simple glitch in the network should not throw exception. - If the destination goes down and another process takes up the task then we will be able to retry. - The client need not be aware of these common use cases. - Some times client may be ok in losing events, then he does not have to do anything special - If they really want to know that a destination is down, they can implement the callback and get notified when the buffer is full. thanks, Kishore G 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) > > >
