[
https://issues.apache.org/jira/browse/HDFS-4437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13562739#comment-13562739
]
Daryn Sharp commented on HDFS-4437:
-----------------------------------
I'm not a lease expert, but how could that happen? My understanding (I haven't
thoroughly studied the code) is the lease is acquired when the file is opened
for writing or appending. If the NN revokes the lease, then the client is
going to fail writing to the file. Even if renamed back, I don't think the
client auto-magically reacquires the lease? Or that block recovery will allow
the client to continue writing?
Even if the use case described can happen, is it really a legitimate use case?
Or at least one that outweighs the more common case of leases being leaked and
never released by daemons or long running tasks? If the "rename, rename-back,
continue-writing" is deemed legitimate, how do we address the leaking leases?
Individual per-file timeouts in the lease instead of timeouts per lease?
> Clients should not retain leases on moved files
> -----------------------------------------------
>
> Key: HDFS-4437
> URL: https://issues.apache.org/jira/browse/HDFS-4437
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 0.23.0, 2.0.0-alpha, 3.0.0
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Priority: Critical
>
> Moving open files and/or parent directories of open files will rewrite the
> leases to the new path. The client is not notified so future stream
> operations will fail. However, as long as the client keeps its lease active
> it will have a "lock" on the file in its new location. This is not good for
> a daemon.
> Leases should be released after the file is moved.
--
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
