incubator-s4-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kishore g <g.kish...@gmail.com>
Subject Re: Handling connection failures in Netty
Date Fri, 11 Nov 2011 21:22:27 GMT
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
<kkambatl@cs.purdue.edu>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 <leoneumeyer@gmail.com>
> 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
> > <kkambatl@cs.purdue.edu>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)
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message