[
https://issues.apache.org/jira/browse/HDFS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767591#action_12767591
]
stack commented on HDFS-127:
----------------------------
+1 on this patch.
Some notes:
+ This patch does not have the issue that hadoop-1911 "fixed" though it moves
the failure counter back to being a local variable. There is no danger that it
"...revert[s]- and reintroduce[s]- HADOOP-1911?" because the patch removes the
catching of exceptions inside chooseDataNode while loop.
+ I am of the opinion that this patch should not be gated on the necessary work
HDFS-656 "Clarify error handling and retry semantics for DFS read path" (nor
HDFS-378 "DFSClient should track failures by block rather than globally").
This patch should actually help some as it narrows scope of the failures
variable. But maybe we can do even more as part of this patch (See below).
If a new patch is cut, the following might be considered:
+ There is no documentation of "dfs.client.max.block.acquire.failures" nor of
what local counter 'failures' means. Above its suggested that we at least doc.
what a failure is ("For e.g. it looks like 'a failure' is defined as not being
able to connect/fetch from all the replicas. Also success is defined as just
being able to get 'ok' from datanode.")
+ By default, "dfs.client.max.block.acquire.failures" is 3. If more than 3
replicas, we could fail though good replicas out on cluster. Should DFSClient
set this.maxBlockAcquireFailures default to max of
dfs.replication/dfs.client.max.block.acquire.failures?
+ I'd put these two LOG.info messages together rather than have two LOG.info
lines:
{code}
if (nodes == null || nodes.length == 0) {
LOG.info("No node available for block: " + blockInfo);
}
LOG.info("Could not obtain block " + block.getBlock()
+ " from any node. Will get new block locations from namenode and
retry...");
{code}
> DFSClient block read failures cause open DFSInputStream to become unusable
> --------------------------------------------------------------------------
>
> Key: HDFS-127
> URL: https://issues.apache.org/jira/browse/HDFS-127
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: hdfs client
> Reporter: Igor Bolotin
> Attachments: 4681.patch, h127_20091016.patch, h127_20091019.patch
>
>
> We are using some Lucene indexes directly from HDFS and for quite long time
> we were using Hadoop version 0.15.3.
> When tried to upgrade to Hadoop 0.19 - index searches started to fail with
> exceptions like:
> 2008-11-13 16:50:20,314 WARN [Listener-4] [] DFSClient : DFS Read:
> java.io.IOException: Could not obtain block: blk_5604690829708125511_15489
> file=/usr/collarity/data/urls-new/part-00000/20081110-163426/_0.tis
> at
> org.apache.hadoop.hdfs.DFSClient$DFSInputStream.chooseDataNode(DFSClient.java:1708)
> at
> org.apache.hadoop.hdfs.DFSClient$DFSInputStream.blockSeekTo(DFSClient.java:1536)
> at org.apache.hadoop.hdfs.DFSClient$DFSInputStream.read(DFSClient.java:1663)
> at java.io.DataInputStream.read(DataInputStream.java:132)
> at
> org.apache.nutch.indexer.FsDirectory$DfsIndexInput.readInternal(FsDirectory.java:174)
> at
> org.apache.lucene.store.BufferedIndexInput.refill(BufferedIndexInput.java:152)
> at
> org.apache.lucene.store.BufferedIndexInput.readByte(BufferedIndexInput.java:38)
> at org.apache.lucene.store.IndexInput.readVInt(IndexInput.java:76)
> at org.apache.lucene.index.TermBuffer.read(TermBuffer.java:63)
> at org.apache.lucene.index.SegmentTermEnum.next(SegmentTermEnum.java:131)
> at org.apache.lucene.index.SegmentTermEnum.scanTo(SegmentTermEnum.java:162)
> at org.apache.lucene.index.TermInfosReader.scanEnum(TermInfosReader.java:223)
> at org.apache.lucene.index.TermInfosReader.get(TermInfosReader.java:217)
> at org.apache.lucene.index.SegmentTermDocs.seek(SegmentTermDocs.java:54)
> ...
> The investigation showed that the root of this issue is that we exceeded # of
> xcievers in the data nodes and that was fixed by changing configuration
> settings to 2k.
> However - one thing that bothered me was that even after datanodes recovered
> from overload and most of client servers had been shut down - we still
> observed errors in the logs of running servers.
> Further investigation showed that fix for HADOOP-1911 introduced another
> problem - the DFSInputStream instance might become unusable once number of
> failures over lifetime of this instance exceeds configured threshold.
> The fix for this specific issue seems to be trivial - just reset failure
> counter before reading next block (patch will be attached shortly).
> This seems to be also related to HADOOP-3185, but I'm not sure I really
> understand necessity of keeping track of failed block accesses in the DFS
> client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
