[
https://issues.apache.org/jira/browse/HDFS-6197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Nauroth updated HDFS-6197:
--------------------------------
Attachment: HDFS-6197.1.patch
Here is the patch.
# Add a fallback code path in {{FileJournalManager#EditLogFile#renameSelf}} to
try deleting the destination if the initial rename fails. This is the same
strategy that we use for handling this situation in
{{FSImage#renameImageFileInDir}}.
# Shutdown a {{MiniDFSCluster}} that was getting leaked in
{{TestRollingUpgrade}}. This had the effect of disrupting a lot of other tests
on Windows, because the leaked cluster continued to hold file locks.
> Rolling upgrade rollback on Windows can fail attempting to rename edit log
> segment files to a destination that already exists.
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-6197
> URL: https://issues.apache.org/jira/browse/HDFS-6197
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 3.0.0, 2.4.0
> Reporter: Chris Nauroth
> Assignee: Chris Nauroth
> Priority: Minor
> Attachments: HDFS-6197.1.patch
>
>
> As part of a rollback from a rolling upgrade in progress, we discard edit log
> segments by renaming the file with suffix ".trash". If no new edits arrive
> in between multiple attempts, then the ".trash" file may still exist. On
> Windows, {{java.io.File#renameTo}} fails if the destination already exists
> though. This is visible right now as a failure in
> {{TestRollingUpgrade#testRollback}} when running on Windows.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
