[
https://issues.apache.org/jira/browse/HDFS-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849796#comment-13849796
]
Colin Patrick McCabe commented on HDFS-5431:
--------------------------------------------
Thanks. This looks a lot better with just one lock, and without the volatiles.
Do we still need both waitForRescan and waitForRescanInternal, given that one
just calls the other?
+1.
bq. I also re-examined close since I was re-doing the synchronization. This
snippet looks like it makes the thread calling close wait for 60 seconds, where
the intent is probably to interrupt the CRM thread and make it cleanly exit:
It probably should not have a timeout, but just use
{{Uninterruptibles#joinUninterruptibly}}. Otherwise we might get into a weird
state where close had been called, but the CRM thread is still running. The
use of {{Thread#isAlive}} shouldn't be required either. Of course, this is
just used in tests anyway, so I'm not too worried about it. But by all means,
file a follow-on.
> support cachepool-based limit management in path-based caching
> --------------------------------------------------------------
>
> Key: HDFS-5431
> URL: https://issues.apache.org/jira/browse/HDFS-5431
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: datanode, namenode
> Affects Versions: 3.0.0
> Reporter: Colin Patrick McCabe
> Assignee: Andrew Wang
> Attachments: hdfs-5431-1.patch, hdfs-5431-2.patch, hdfs-5431-3.patch,
> hdfs-5431-4.patch, hdfs-5431-5.patch, hdfs-5431-6.patch
>
>
> We should support cachepool-based limit management in path-based caching.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
