incubator-s4-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karthik Kambatla <kkamb...@cs.purdue.edu>
Subject Re: Handling connection failures in Netty
Date Fri, 11 Nov 2011 22:04:30 GMT
Kishore,

One buffer per destination node seems fair enough. If we are maintaining
buffers, how about just queue messages into this buffer on call to send(),
we can have another thread sending messages on these buffers across.

Leo,

It is true that the application can't do much, however the application can
choose to forget the old messages and see if the new messages can be sent
across. The buffers that Kishore suggested can be circular, indicating to
the application a full buffer from time to time.

Thanks
Karthik

On Fri, Nov 11, 2011 at 4:29 PM, Leo Neumeyer <leoneumeyer@gmail.com> wrote:

> 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
> <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)
> > >
> >
>
>
>
> --
>
> Leo Neumeyer (@leoneu)
>

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