[
https://issues.apache.org/jira/browse/HDFS-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Nauroth updated HDFS-4752:
--------------------------------
Attachment: HDFS-4752.2.patch
On further reflection, I'm inclined to skip this test on Windows. The file
locking could actually be a desirable behavior for preventing accidental
deletion of a replica. I'm reluctant to introduce potentially dangerous
configuration hooks just to satisfy the test, as was done in patch version 1.
Instead, I'm uploaing patch version 2 to skip the test on Windows.
My only other concern was around the potential for concurrent deleteBlockPool
operations. However, the CLI documentation for deleteBlockPool states that the
operator must use refreshNamenodes first so that there is no live activity on
the block pool. This means that we have not committed to supporting a
concurrent deleteBlockPool, and therefore we do not need share-delete semantics.
{code}
String deleteBlockPool = "-deleteBlockPool: Arguments are
datanodehost:port, blockpool id\n"+
"\t\t and an optional argument \"force\". If force
is passed,\n"+
"\t\t block pool directory for the given blockpool
id on the given\n"+
"\t\t datanode is deleted along with its contents,
otherwise\n"+
"\t\t the directory is deleted only if it is
empty. The command\n" +
"\t\t will fail if datanode is still serving the
block pool.\n" +
"\t\t Refer to refreshNamenodes to shutdown a
block pool\n" +
"\t\t service on a datanode.\n";
{code}
> TestRBWBlockInvalidation fails on Windows due to file locking
> -------------------------------------------------------------
>
> Key: HDFS-4752
> URL: https://issues.apache.org/jira/browse/HDFS-4752
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: datanode, test
> Affects Versions: 3.0.0
> Reporter: Chris Nauroth
> Assignee: Chris Nauroth
> Attachments: HDFS-4752.1.patch, HDFS-4752.2.patch
>
>
> The test attempts to invalidate a block by deleting its block file and meta
> file. This happens while a datanode thread holds the files open for write.
> On Windows, this causes a locking conflict, and the test fails.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
