[
https://issues.apache.org/jira/browse/HDFS-7463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14233614#comment-14233614
]
Charles Lamb commented on HDFS-7463:
------------------------------------
Hi [~wheat9],
Interesting improvement. Thanks for doing this.
FSNamesystem.java:
#getBlockLocations. Should 'now' be set inside the writeLock()? It's possible
that acquiring the lock might take time and then now would be earlier than it
should be. I notice that the previous code sets now() inside the writelock, as
does your new code with the readlock().
I guess I'd feel a little better if there were appropriate getters on
GetBlockLocationsResult, rather than (say) direct access to 'blocks' with
.blocks, but I don't feel strongly.
NameNodeAdaptor.java:
You removed the sub-exceptions from #getFileInfo's throws decl in favor of the
superclass (IOException), but my impression is that those are generally decl'd
(even though the appear as unused in an IDE) for clarity. Often it is good to
have those for figuring out what exceptions to unwrap on the client side, right?
Charles
> Simplify FSNamesystem#getBlockLocationsUpdateTimes
> --------------------------------------------------
>
> Key: HDFS-7463
> URL: https://issues.apache.org/jira/browse/HDFS-7463
> Project: Hadoop HDFS
> Issue Type: Improvement
> Reporter: Haohui Mai
> Assignee: Haohui Mai
> Attachments: HDFS-7463.000.patch, HDFS-7463.001.patch
>
>
> Currently {{FSNamesystem#getBlockLocationsUpdateTimes}} holds the read lock
> to access the blocks. It releases the read lock and then acquires the write
> lock when it needs to update the access time of the {{INode}}.
> This jira proposes to move the responsibility of the latter steps to the
> caller to simplify the code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
