[
https://issues.apache.org/jira/browse/HDFS-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291479#comment-13291479
]
Colin Patrick McCabe commented on HDFS-3190:
--------------------------------------------
It's good to see some cleanup.
Hmm. LongContainingFile just seems like a containing file that is long.
How does SingleValueFile seem as a class name? Then you could have
SingleValueFile#readLong and SingleValueFile#writeLong.
{code}
+ public static long read(File file, long defaultVal) throws IOException {
+ long txid = defaultVal;
+ // TODO: canRead below seems wrong
+ if (file.exists() && file.canRead()) {
+ BufferedReader br = new BufferedReader(new FileReader(file));
+ try {
+ txid = Long.valueOf(br.readLine());
+ br.close();
+ br = null;
+ } finally {
+ IOUtils.cleanup(LOG, br);
+ }
+ }
+ return txid;
+ }
{code}
Yeah, I agree that the canRead() seems unecessary.
It's unfortunate that the BufferedReader constructor always throws a
FileNotFound exception, even if the file *is* found but simply is not readable.
However, despite the misnamed exception, if you get rid of the canRead(), you
should have the semantic that file not found => default, file not readable =>
IOException, which I think is what you want.
> Simple refactors in existing NN code to assist QuorumJournalManager extension
> -----------------------------------------------------------------------------
>
> Key: HDFS-3190
> URL: https://issues.apache.org/jira/browse/HDFS-3190
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: name-node
> Affects Versions: 2.0.0-alpha
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Minor
> Attachments: hdfs-3190.txt, hdfs-3190.txt
>
>
> This JIRA is for some simple refactors in the NN:
> - refactor the code which writes the seen_txid file in NNStorage into a new
> "LongContainingFile" utility class. This is useful for the JournalNode to
> atomically/durably record its last promised epoch
> - refactor the interface from FileJournalManager back to StorageDirectory to
> use a StorageErrorReport interface. This allows FileJournalManager to be used
> in isolation of a full StorageDirectory.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
