[
https://issues.apache.org/jira/browse/HDFS-7718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun Suresh updated HDFS-7718:
------------------------------
Attachment: HDFS-7718.3.patch
Thanks for the review [~cmccabe]. Attaching updated patch..
bq. Rather than looking up providerUriStr again, let's pass it in from the get
function. We already checked in that function that it was non-null, so we don't
need to check again.
I apologize, but I do not really follow this.. if you look at the latest patch,
the only place conf string the lookup is happening is in
{{createKeyProviderURI}}
Also, this function is used by the {{setKeyProvider}} method which has to take
a conf as argument.. so I really need to pass a conf into the
createKeyProviderURI method.
bq. This shouldn't be checked in?
Yup.. it needs to be there (The KeyProviders use the
{{java.util.ServiceLoader}} which require the factory name specified like this)
I have address all the rest of your concerns..
> 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, HDFS-7718.2.patch, HDFS-7718.3.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)
