[
https://issues.apache.org/jira/browse/HDFS-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727893#action_12727893
]
Konstantin Shvachko commented on HDFS-278:
------------------------------------------
# In (4) I meant that in {{LeaseChecker.run()}} if you move {{clientRunning =
false;}} and {{RPC.stopProxy()}} - two lines surronding abort() - if you move
them inside abprt, then you will not need the synchronized section around these
three lines, because {{abort()}} is synchronized already.
# It is better to use {{LOG.warn(message, excpetion)}} instead
{{LOG.warn(message + excpetion + anotherMessage)}} since you will se the stack
trace in the former case. I see you replaced the original usage by this on 2
occasions.
+1 other than that.
> Should DFS outputstream's close wait forever?
> ---------------------------------------------
>
> Key: HDFS-278
> URL: https://issues.apache.org/jira/browse/HDFS-278
> Project: Hadoop HDFS
> Issue Type: Improvement
> Reporter: Raghu Angadi
> Assignee: dhruba borthakur
> Attachments: softMount1.patch, softMount1.patch, softMount2.patch,
> softMount3.patch, softMount4.txt, softMount5.txt, softMount6.txt,
> softMount7.txt
>
>
> Currently {{DFSOutputStream.close()}} waits for ever if Namenode keeps
> throwing {{NotYetReplicated}} exception, for whatever reason. Its pretty
> annoying for a user. Shoud the loop inside close have a timeout? If so how
> much? It could probably something like 10 minutes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
