[ 
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)

Reply via email to