You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "Colin Patrick McCabe (JIRA)" <ji...@apache.org> on 2015/03/11 04:11:38 UTC
[jira] [Commented] (HDFS-7915) The DataNode can sometimes allocate
a ShortCircuitShm slot and fail to tell the DFSClient about it because of a
network error
[ https://issues.apache.org/jira/browse/HDFS-7915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14356156#comment-14356156 ]
Colin Patrick McCabe commented on HDFS-7915:
--------------------------------------------
I think putting the "unregister slot" code into a "finally" block that covers the whole function should fix this. Since the I/O we're dealing with is local (never touches the network because this is for short circuit) we can be pretty confident that if the {{write}} succeeds, the {{DFSClient}} knows about what we sent.
> The DataNode can sometimes allocate a ShortCircuitShm slot and fail to tell the DFSClient about it because of a network error
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-7915
> URL: https://issues.apache.org/jira/browse/HDFS-7915
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.7.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
>
> The DataNode can sometimes allocate a ShortCircuitShm slot and fail to tell the DFSClient about it because of a network error. In {{DataXceiver#requestShortCircuitFds}}, the DataNode can succeed at the first part (mark the slot as used) and fail at the second part (tell the DFSClient what it did). The "try" block for unregistering the slot only covers a failure in the first part, not the second part. In this way, a divergence can form between the views of which slots are allocated on DFSClient and on server.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)