[
https://issues.apache.org/jira/browse/HDFS-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13713054#comment-13713054
]
Jing Zhao commented on HDFS-4979:
---------------------------------
1. For FSNamesystem#renameTo(String, String, Options.Rename...), resultingStat
can be null even if the rename succeeded (if audit is disabled). So maybe we
need other mechanism to check if the rename succeeds or not?
2. In FSNamesystem#startFile, suppose after request 1 succeeded, the file got
deleted. Then another two retry requests r2 and r3 came. Both will find that
the current entry's state is Success, and go into getFileStatus() one by one.
It is possible that both will get a null result from getFileStatus. In that
case, both will run the startFileInt. Thus we may need some further
synchronization mechanism here (e.g., set the entry's state to InProgress while
the retry op is checking the current status).
3. Now some RetryCache#setState calls are out of the FSNamesystem lock while
some are within the lock (e.g., deleteSnapshot, createSnapshot, etc). Maybe we
can make it consistent by moving all of them out of the FSNamesystem lock?
> Implement retry cache on the namenode
> -------------------------------------
>
> Key: HDFS-4979
> URL: https://issues.apache.org/jira/browse/HDFS-4979
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: namenode
> Reporter: Suresh Srinivas
> Assignee: Suresh Srinivas
> Attachments: HDFS-4979.1.patch, HDFS-4979.2.patch, HDFS-4979.3.patch,
> HDFS-4979.4.patch, HDFS-4979.5.patch, HDFS-4979.patch
>
>
--
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
