Details
-
Sub-task
-
Status: Closed
-
Blocker
-
Resolution: Fixed
-
0.20-append, 0.21.0, 0.22.0
-
None
-
Reviewed
Description
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.
Attachments
Attachments
Issue Links
- is related to
-
HDFS-1401 TestFileConcurrentReader test case is still timing out / failing
- Resolved
-
HDFS-1103 Replica recovery doesn't distinguish between flushed-but-corrupted last chunk and unflushed last chunk
- Resolved
-
HDFS-1679 TestFileConcurrentReader fails intermittently
- Resolved
-
HDFS-1885 Recurring failures in TestFileConcurrentReader for > 12 days
- Resolved
-
HDFS-1310 TestFileConcurrentReader fails
- Closed
- relates to
-
HDFS-3719 Re-enable append-related tests in TestFileConcurrentReader
- Reopened
-
HADOOP-7146 RPC server leaks file descriptors
- Closed