[
https://issues.apache.org/jira/browse/HDFS-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869880#action_12869880
]
Todd Lipcon commented on HDFS-1142:
-----------------------------------
The question I asked above still stands:
{quote}
Here's a question - as you described it, the original lease holder and the
recovering lease holder race to recover the lease. If the original holder wins
the recovery, are we guaranteed that no interceding appends have occurred? eg
what happens if the recovering process wins, opens the file for append, and
immediately closes it. Are we guaranteed then that another flush() call from
the client at that point would definitely fail, or can it transparently regain
the lease from the now-closed file?
{quote}
If the above situation is prevented, I think we can rejigger the "recoverFile"
operation that HBase does, and make this work. If the above is not prevented,
we have to think harder. Maybe we can still do it by renaming the files after
recovering the lease (since iirc in 21 the lease holder can rename a file that
it holds open for write)
> Lease recovery doesn't reassign lease when triggered by append()
> ----------------------------------------------------------------
>
> Key: HDFS-1142
> URL: https://issues.apache.org/jira/browse/HDFS-1142
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.21.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Attachments: hdfs-1142.txt, hdfs-1142.txt
>
>
> If a soft lease has expired and another writer calls append(), it triggers
> lease recovery but doesn't reassign the lease to a new owner. Therefore, the
> old writer can continue to allocate new blocks, try to steal back the lease,
> etc. This is for the testRecoveryOnBlockBoundary case of HDFS-1139
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
