As far I know, Netty uses its own settings to control timeouts and other
socket options. Unfortunately I don't think there is a workaround without
applying the patch.
Maybe NettyTransceiver should expose a constructor that allows a
ClientBootstrap to be passed in so that users can control exactly how
sockets are created if necessary. If that constructor were present then
there would have been a workaround for the timeout issue. I think I'll
update the AVRO-943 patch to include that change.
On Mon, Oct 31, 2011 at 1:18 PM, Yang <[EMAIL PROTECTED]> wrote:
> thanks James.
> "because no timeout is used....", is it possible to specify a timeout
> for the current nettyTransceiver code? the normal SO_TIMEOUT applies
> to Socket, but it seems NettyTransceiver does not take a Socket input
> in constructor.
> On Mon, Oct 31, 2011 at 10:10 AM, James Baldassari
> <[EMAIL PROTECTED]> wrote:
> > Hi Yang,
> > NettyTransceiver tries to automatically reconnect if the connection is
> > lost. Sometimes it gets stuck because no timeout is used on the
> > as you mentioned. Please see this issue for a patch:
> > https://issues.apache.org/jira/browse/AVRO-943
> > -James
> > On Mon, Oct 31, 2011 at 1:07 PM, Yang <[EMAIL PROTECTED]> wrote:
> >> it looks
> >> NettyTransceiver.getChannel().getChannelConfig().setTimeoutMillis()
> >> could be a possible approach?
> >> On Mon, Oct 31, 2011 at 9:41 AM, Yang <[EMAIL PROTECTED]> wrote:
> >> > this is more of a problem on TCP itself: if I have a TCP connection
> >> > established, then
> >> > I pull out the network cable, the TCP connection is still on, as soon
> >> > as I re-connect the cable.
> >> >
> >> > in the case of Avro RPC call, if I pull out the cable, the RPC just
> >> > blocks, without throwing an exception.
> >> > I see https://issues.apache.org/jira/browse/FLUME-313 addressing
> >> > this for HTTP transceiver,
> >> > is there a similar patch for NettyTransceiver?
> >> >
> >> > Thanks
> >> > Yang
> >> >