[ https://issues.apache.org/jira/browse/HDFS-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14080370#comment-14080370 ]
Colin Patrick McCabe commented on HDFS-6783: -------------------------------------------- OK. So the concern is a race between {code} isScanning = true; needsRescan = false; } finally { lock.unlock(); } {code} And code that calls {{setNeedsRescan}} followed by {{waitForRescanIfNeeded}}. Since there are so many code paths that drop the lock in between those two calls, this could certainly happen, I think. This patch would cause us to wait for even rescans that were not triggered by {{needsRescan}}, though. We probably need some kind of scan epoch system to do this right... > Fix not really wait for rescan in HDFS CacheReplicationModitor > -------------------------------------------------------------- > > Key: HDFS-6783 > URL: https://issues.apache.org/jira/browse/HDFS-6783 > Project: Hadoop HDFS > Issue Type: Bug > Components: caching > Affects Versions: 3.0.0 > Reporter: Yi Liu > Assignee: Yi Liu > Attachments: HDFS-6783.001.patch > > > In monitor thread, needsRescan is set to false before real scan starts, so > for {{waitForRescanIfNeeded}} will return for the first condition: > {code} > if (!needsRescan) { > return; > } > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)