[
https://issues.apache.org/jira/browse/HDFS-11210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15852474#comment-15852474
]
Andrew Wang commented on HDFS-11210:
------------------------------------
Thanks for the rev Xiao, looks pretty close, mostly nitty stuff and questions:
* index.md.vm, new entry on getMetadata looks incomplete?
* TestKMS, typo MockVersinoName
* Since readLock and writeLock both need to call into a synchronized block to
do anything, it might limit performance. I don't know if ValueQueue is actually
performance critical, but one approach to solve this is preallocating an array
of locks and using striped locking. Essentially, hash the key, and use the lock
at that array location. This spreads out load across the locks well assuming
the hash function is good. Resizing the array of locks is an exercise left to
the reader.
* Are the createLockIfNonexist calls in readLock and writeLock sufficient for
safety, or do we need the other calls too? Would prefer to remove the other
calls for clarity if they're not necessary.
* Do you know why UniqueKeyBlockingQueue#put is synchronized, but the other
methods aren't?
* KMSClientProvider#invalidateCache, little nit, please move the comment up
above where we invalidate the server cache
* Final q, it looks like we'll invalidate multiple times since there's an
invalidateCache call in both KMSCP and LBKMSCP. Do you think we can remove the
invalidates in LBKMSCP?
> Enhance key rolling to guarantee new KeyVersion is returned from
> generateEncryptedKeys after a key is rolled
> ------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-11210
> URL: https://issues.apache.org/jira/browse/HDFS-11210
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: encryption, kms
> Affects Versions: 2.6.5
> Reporter: Xiao Chen
> Assignee: Xiao Chen
> Attachments: HDFS-11210.01.patch, HDFS-11210.02.patch,
> HDFS-11210.03.patch
>
>
> To support re-encrypting EDEK, we need to make sure after a key is rolled, no
> old version EDEKs are used anymore. This includes various caches when
> generating EDEK.
> This is not true currently, simply because no such requirements / necessities
> before.
> This includes
> - Client Provider(s), and corresponding cache(s).
> When LoadBalancingKMSCP is used, we need to clear all KMSCPs.
> - KMS server instance(s), and corresponding cache(s)
> When KMS HA is configured with multiple KMS instances, only 1 will receive
> the {{rollNewVersion}} request, we need to make sure other instances are
> rolled too.
> - The Client instance inside NN(s), and corresponding cache(s)
> When {{hadoop key roll}} is succeeded, the client provider inside NN should
> be drained too.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
