[ https://issues.apache.org/jira/browse/HDFS-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15061297#comment-15061297 ]
Jing Zhao commented on HDFS-7964: --------------------------------- The patch looks good to me. One nit is that two places in FSEditLogAsync have some commented code: {code} //if (LOG.isDebugEnabled()) { LOG.info("logSync "+edit); //} {code} +1 after addressing this. Besides, the current postponeResponse/sendResponse code uses a counter to delay the response. This looks a little hacky to me. But I understand this may be the only way to add the new functionality without changing the original code. Maybe we can do some extra refactoring in the future. > Add support for async edit logging > ---------------------------------- > > Key: HDFS-7964 > URL: https://issues.apache.org/jira/browse/HDFS-7964 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: namenode > Affects Versions: 2.0.2-alpha > Reporter: Daryn Sharp > Assignee: Daryn Sharp > Attachments: HDFS-7964.patch, HDFS-7964.patch, HDFS-7964.patch > > > Edit logging is a major source of contention within the NN. LogEdit is > called within the namespace write log, while logSync is called outside of the > lock to allow greater concurrency. The handler thread remains busy until > logSync returns to provide the client with a durability guarantee for the > response. > Write heavy RPC load and/or slow IO causes handlers to stall in logSync. > Although the write lock is not held, readers are limited/starved and the call > queue fills. Combining an edit log thread with postponed RPC responses from > HADOOP-10300 will provide the same durability guarantee but immediately free > up the handlers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)