[
https://issues.apache.org/jira/browse/HDFS-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882644#action_12882644
]
sam rash commented on HDFS-1057:
--------------------------------
sorry, i don't understand. this is a race condition where the namenode has
assigned locations to the block, but the client hasn't sent data yet. the NN
cannot know that the DNs don't have data on disk yet unless we add additional
NN coordination? our choice in this condition is to return 0 or let the
exception be. I had done the latter, but you asked for the former unless I
misunderstood.
can you clarify what you want?
> Concurrent readers hit ChecksumExceptions if following a writer to very end
> of file
> -----------------------------------------------------------------------------------
>
> Key: HDFS-1057
> URL: https://issues.apache.org/jira/browse/HDFS-1057
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: data-node
> Affects Versions: 0.20-append, 0.21.0, 0.22.0
> Reporter: Todd Lipcon
> Assignee: sam rash
> Priority: Blocker
> Fix For: 0.20-append
>
> Attachments: conurrent-reader-patch-1.txt,
> conurrent-reader-patch-2.txt, conurrent-reader-patch-3.txt,
> HDFS-1057-0.20-append.patch, hdfs-1057-trunk-1.txt, hdfs-1057-trunk-2.txt,
> hdfs-1057-trunk-3.txt, hdfs-1057-trunk-4.txt
>
>
> In BlockReceiver.receivePacket, it calls replicaInfo.setBytesOnDisk before
> calling flush(). Therefore, if there is a concurrent reader, it's possible to
> race here - the reader will see the new length while those bytes are still in
> the buffers of BlockReceiver. Thus the client will potentially see checksum
> errors or EOFs. Additionally, the last checksum chunk of the file is made
> accessible to readers even though it is not stable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
