[
https://issues.apache.org/jira/browse/HDFS-7718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14301880#comment-14301880
]
Colin Patrick McCabe commented on HDFS-7718:
--------------------------------------------
{code}
3465 public KeyProvider getKeyProvider() {
3466 // if KeyProvider explicitly set (mostly for testing), return it
3467 // else get from clientContext
3468 if (provider != null) {
3469 return provider;
3470 }
3471 try {
3472 return clientContext.getKeyProviderCache().get(conf);
3473 } catch (IOException e) {
3474 LOG.error("Could not obtain KeyProvider !!", e);
3475 return null;
3476 }
3473 }
{code}
I don't think we need this complexity. Just have the unit test set up the
{{ClientContext}}.
{code}
772 public static final long DFS_CLIENT_KEY_PROVIDER_CACHE_EXPIRY_DEFAULT
=
773 10 * 24 * 60 * 60 * 1000;
{code}
Can you use {{TimeUnit}} for this?
{code}
private final Cache<URI, KeyProvider> cache;
{code}
Should we be comparing the URIs as strings instead? I'm not that familiar with
{{URI#equals}}, what features of it make it the right thing here?
there are a few whitespace changes that don't seem necessary.
> DFSClient objects created by AbstractFileSystem objects created by
> FileContext are not closed and results in thread leakage
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-7718
> URL: https://issues.apache.org/jira/browse/HDFS-7718
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Arun Suresh
> Assignee: Arun Suresh
> Attachments: HDFS-7718.1.patch
>
>
> Currently, the {{FileContext}} class used by clients such as (for eg.
> {{YARNRunner}}) creates a new {{AbstractFilesystem}} object on
> initialization.. which creates a new {{DFSClient}} object.. which in turn
> creates a KeyProvider object.. If Encryption is turned on, and https is
> turned on, the keyprovider implementation (the {{KMSClientProvider}}) will
> create a {{ReloadingX509TrustManager}} thread per instance... which are never
> killed and can lead to a thread leak
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
