[
https://issues.apache.org/jira/browse/HDFS-9405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15196937#comment-15196937
]
Andrew Wang commented on HDFS-9405:
-----------------------------------
A few review comments, sorry for coming into this late. Overall looks good
though, nice work here Xiao!
* Can we use an array rather than LinkedList in getAllKeyNames()? I see it gets
toArray'd later on, we can save some allocations.
* Recommend rename getAllKeyNames to just getKeyNames, unless there is a place
where we get some but not all keys
* Typo: "retiresLeft" rather than "retriesLeft"
* Have you considered using a SingleThreadExecutor to handle the thread
lifetime? Recommend also using Guava's ThreadFactoryBuilder, since you can also
give the thread a human-friendly name for nice jstack output, and also lets you
make it a daemon thread.
* In the test, should we add a waitFor in case the thread hasn't finished
filling the EDEK cache? The filling is async, so I expected some kind of
blocking/waiting for the check.
> When starting a file, NameNode should generate EDEK in a separate thread
> ------------------------------------------------------------------------
>
> Key: HDFS-9405
> URL: https://issues.apache.org/jira/browse/HDFS-9405
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: encryption, namenode
> Affects Versions: 2.7.1
> Reporter: Zhe Zhang
> Assignee: Xiao Chen
> Attachments: HDFS-9405.01.patch, HDFS-9405.02.patch,
> HDFS-9405.03.patch, HDFS-9405.04.patch, HDFS-9405.05.patch,
> HDFS-9405.06.patch, HDFS-9405.07.patch
>
>
> {{generateEncryptedDataEncryptionKey}} involves a non-trivial I/O operation
> to the key provider, which could be slow or cause timeout. It should be done
> as a separate thread so as to return a proper error message to the RPC caller.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
