On Wed, Dec 23, 2009 at 2:24 PM, Ken Weiner <[email protected]> wrote: > HBase itself isn't complaining. I only see the error from Hadoop. I wasn't > sure if there are some side effects I'm not aware of. Is it causing any > problems to my application?
IIUC, nothing but some extra latency while the dropped socket is reestablished. > I see the error occur even when my system is > under relatively light load with no MR jobs running. I also forgot to > mention that I saw this error with HBase 0.20.0/Hadoop 0.20.0 and I > recently > upgraded to HBase 0.20.2/Hadoop 0.20.1 and the error still occurs at the > same rate after the upgrade. > > Yeah. This would not be surprising. This is hdfs behavior. You could up the default timeout in hdfs if you wanted less incidence: dfs.datanode.socket.write.timeout. But, then sockets would never timeout. St.Ack > Ken > > On Wed, Dec 23, 2009 at 11:49 AM, stack <[email protected]> wrote: > > > Yeah, see HADOOP-3831. It looks like datanode timing out unused > > connections. As I understand it, later, when dfsclient wants to use this > > block, it just sets up the socket again -- silently, transparently below > > the > > level at which the application can see. Do I have it right? Is hbase > > itself complaining? > > > > St.Ack > > > > >
