[ https://issues.apache.org/jira/browse/HADOOP-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15299261#comment-15299261 ]
Junping Du commented on HADOOP-10048: ------------------------------------- Thanks [~jlowe] for updating the patch. I am OK with lockless approach to solve the problem. However, in the existing patch (004), it seems cannot guarantee the consistency for Async call of {{getLocalPathForWrite(.., conf, ...)}} with conf in multi-thread case if conf get changed. Consider the case that thread A (conf1) and thread B (conf2) call this method at the same time: thread A hit confChanged() with conf1 first, then thread B hit confChanged() with conf2, afterwards thread A going forward to get path for write that is based on conf2 now - that means thread A could get a path that is not existed in conf1. I think we should keep the consistency between API's return result and parameter, like: we can let confChanged() return a thread local Context object and do the following thing with this local context. What do you think? > LocalDirAllocator should avoid holding locks while accessing the filesystem > --------------------------------------------------------------------------- > > Key: HADOOP-10048 > URL: https://issues.apache.org/jira/browse/HADOOP-10048 > Project: Hadoop Common > Issue Type: Improvement > Affects Versions: 2.3.0 > Reporter: Jason Lowe > Assignee: Jason Lowe > Attachments: HADOOP-10048.003.patch, HADOOP-10048.004.patch, > HADOOP-10048.patch, HADOOP-10048.trunk.patch > > > As noted in MAPREDUCE-5584 and HADOOP-7016, LocalDirAllocator can be a > bottleneck for multithreaded setups like the ShuffleHandler. We should > consider moving to a lockless design or minimizing the critical sections to a > very small amount of time that does not involve I/O operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org