[
https://issues.apache.org/jira/browse/HDFS-11885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032077#comment-16032077
]
Xiao Chen commented on HDFS-11885:
----------------------------------
Thanks Andrew for revving and the pointer. latest patch LGTM, +1 pending
pre-commit fixes.
I think Rushabh's comment here was for startFile (generateEDEK's cache miss,
same as your #1)?
{quote}
We have an internal patch for namenode throwing retriable exception instead of
making a synchronous call to kms in case of cache miss.
{quote}
Happy to follow it up on HDFS-11804.
Regarding {{ensureKeyIsInitialized}}'s {{provider.getMetadata(keyName)}},
that's a [synchronized call without client-side
caches|https://github.com/apache/hadoop/blob/4369690ce63566131aee28696bf2683a3cb20205/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/kms/KMSClientProvider.java#L907]
right? I think we need to fix it in another follow on, since both this jira
and HDFS-11804 doesn't seem to touch there.
> createEncryptionZone should not block on initializing EDEK cache
> ----------------------------------------------------------------
>
> Key: HDFS-11885
> URL: https://issues.apache.org/jira/browse/HDFS-11885
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: encryption
> Affects Versions: 2.6.5
> Reporter: Andrew Wang
> Assignee: Andrew Wang
> Priority: Critical
> Attachments: HDFS-11885.001.patch, HDFS-11885.002.patch
>
>
> When creating an encryption zone, we call {{ensureKeyIsInitialized}}, which
> calls {{provider.warmUpEncryptedKeys(keyName)}}. This is a blocking call,
> which attempts to fill the key cache up to the low watermark.
> If the KMS is down or slow, this can take a very long time, and cause the
> createZone RPC to fail with a timeout.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
