[
https://issues.apache.org/jira/browse/HDFS-11885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16113358#comment-16113358
]
Daryn Sharp commented on HDFS-11885:
------------------------------------
bq. I think there's still some value here, since we're looking at usecases
involving HSM key providers. HSMs are a lot slower at generating DEKs than
/dev/random. To give you an idea, during testing we blew the 60s RPC timeout
while waiting for the cache to fill to the low watermark (30 keys). We'd really
like the cache to be warmed up before a workload hits the EZ.
With the current design, I see the motivation. However, if Rushabh posts the
patch we've been running internally which basically throws retriable if no EDEK
is available, yet has kicked off an async fetch, can we entirely get rid of the
warmup code?
> 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,
> HDFS-11885.003.patch, HDFS-11885.004.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.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
