[
https://issues.apache.org/jira/browse/HADOOP-11071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125826#comment-14125826
]
Andrew Wang commented on HADOOP-11071:
--------------------------------------
I took a closer look at this, with synchronization in mind. The hypothetical
concern here would be that an async filler thread might be putting an old key
when the drain happens. Additionally, the Oracle docs say that
BlockingQueue#addAll isn't atomic, so {{keyQueue.addAll}} in the
{{fillQueueForKey}} implementations is suspect. We likely need to add some
locking.
Regarding testing, is there a way to test that before rolling, there's a cached
key on both the client and server side, and then after, there isn't on either?
Thanks Tucu.
> KMSClientProvider should drain the local generated EEK cache on key rollover
> ----------------------------------------------------------------------------
>
> Key: HADOOP-11071
> URL: https://issues.apache.org/jira/browse/HADOOP-11071
> Project: Hadoop Common
> Issue Type: Test
> Components: security
> Affects Versions: 2.6.0
> Reporter: Alejandro Abdelnur
> Assignee: Alejandro Abdelnur
> Priority: Minor
> Attachments: HADOOP-11071.patch, HADOOP-11071.patch,
> HADOOP-11071.patch, HADOOP-11071.patch
>
>
> This is for formal correctness and to enable HDFS EZ to verify a rollover
> when testing with KMS
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
