[
https://issues.apache.org/jira/browse/HDFS-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14081502#comment-14081502
]
Colin Patrick McCabe commented on HDFS-6783:
--------------------------------------------
Hi Yi.
I didn't like v2 of the patch since I felt like 2 and 1 were magic numbers, not
obvious when reading the code. I also feel like having all these flags and
conditions and suchlike is kind of brittle.
I would rather just have three numbers: the number of the last completed scan,
the number of the scan in progress, and the number of the next scan that has
been requested. The nice thing about this approach is that if we call
{{setNeedsRescan}} multiple times in a row during the same scan, it just keeps
setting {{neededScanCount}} to the same value. This also doesn't make any
assumptions about whether we hold the FSN lock for the entire duration of
{{CacheReplicationMonitor#rescan}}.
I posted a v3 of the patch that implements this. I think this also solves the
issue in HDFS-6784.
I apologize for posting my patch on your JIRA but I really felt like this was
an awesome solution. Let me know what you think!
> Fix HDFS CacheReplicationMonitor rescan logic
> ---------------------------------------------
>
> 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, HDFS-6783.002.patch,
> HDFS-6783.003.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)
