[
https://issues.apache.org/jira/browse/HDFS-6971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140249#comment-14140249
]
Andrew Wang commented on HDFS-6971:
-----------------------------------
So we actually have caches in a number of places :) The CachingKeyProvider is
actually on the KMS. On the NN side, we're interacting with the
KMSClientProvider. If you look at KMSClientProvider#generateEncryptedKey,
you'll see it interacting with a ValueQueue, which is the cache I was thinking
about. I don't think this is time-bounded.
If you could, you can also double check that CachingKeyProvider drops its
cached encrypted keys at the right times, i.e. on modify ops like deleteKey and
rollNewVersion. As long as it does so, I think we should be up-to-date.
> Bounded staleness of EDEK caches on the NN
> ------------------------------------------
>
> Key: HDFS-6971
> URL: https://issues.apache.org/jira/browse/HDFS-6971
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: encryption
> Affects Versions: 2.5.0
> Reporter: Andrew Wang
> Assignee: Zhe Zhang
>
> The EDEK cache on the NN can hold onto keys after the admin has rolled the
> key. It'd be good to time-bound the caches, perhaps also providing an
> explicit "flush" command.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
