[
https://issues.apache.org/jira/browse/HDFS-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264813#comment-14264813
]
Colin Patrick McCabe commented on HDFS-7496:
--------------------------------------------
It is clever to have {{FsVolumeReference}} so that we can take advantage of the
Java 7 close block idiom. If we are going to do this, though, we should pass
around {{FsVolumeReference}} rather than {{FsVolumeSpi}}, and provide a method
to get the volume out of the VolumeReference. That way, findbugs will warn if
someone forgets to close something that was passed in.
{{BlockReceiver.java}}: I see an {{unreference}} here, but no {{reference}}.
The constructor of {{BlockReceiver}} needs to take an {{FsVolumeReference}} so
that we know we can actually write the block.
{{FsDatasetAsyncDiskService#deleteAsync}}: we should not be passing in an
{{FsVolumeSpi}}. We should be passing in an {{FsVolumeReference}}. Let the
caller handle closing it.
{{FsDatasetAsyncDiskService#moveBlockAcrossStorage}}: I see an {{unreference}},
but no {{reference}}. I assume it's hidden somewhere in the first part of the
function. Again, to repeat, we should be getting an {{FsVolumeReference}}
here, so that it's clear who created the reference and how long it's supposed
to last.
Similar comments for the rest. References, not raw volume objects. Otherwise
it gets too confusing.
thanks Eddy
> Fix FsVolume removal race conditions on the DataNode
> -----------------------------------------------------
>
> Key: HDFS-7496
> URL: https://issues.apache.org/jira/browse/HDFS-7496
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Colin Patrick McCabe
> Assignee: Lei (Eddy) Xu
> Attachments: HDFS-7496.000.patch, HDFS-7496.001.patch
>
>
> We discussed a few FsVolume removal race conditions on the DataNode in
> HDFS-7489. We should figure out a way to make removing an FsVolume safe.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
