[
https://issues.apache.org/jira/browse/HADOOP-11892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15238287#comment-15238287
]
Xiao Chen commented on HADOOP-11892:
------------------------------------
Thanks Arun for creating this. I'm trying to see if my understanding is correct.
Per my understanding, the main concern here is that, some secure random
implementation opens file descriptor /dev/urandom (e.g. {{OsSecureRandom}}).
For each call to {{CryptoCodec#getInstance}}, a new {{CryptoCodec}} object is
created. If that happens to be {{OpensslAesCtrCryptoCodec}}, then at its
{{setConf}} method, {{Random}} object is created. If this happens to be
{{OsSecureRandom}}, then we open a fd. With too many of those calls we would
end up with too many open fd's.
HADOOP-11891 fixes this in some sense by lazily filling the Reservoir. This
jira would also alleviate the problem by adding caches to the {{CryptoCodec}}
object, which in turn caches the {{Random}} object.
If any of this happens again, we should check from jstack to see exactly
how/where the fd's are opened.
Do I understand this correctly? Thanks!
> CryptoCodec#getInstance always returns a new instance of CryptoCodec. This
> could be expensive
> ---------------------------------------------------------------------------------------------
>
> Key: HADOOP-11892
> URL: https://issues.apache.org/jira/browse/HADOOP-11892
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 2.7.0
> Reporter: Arun Suresh
> Assignee: Arun Suresh
>
> {{CryptoCodec#getInsatnce}} should be able to return possibly cached
> instances of the CryptoCodec implementation as instantiating a new instance
> every time could be expensive
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
