[
https://issues.apache.org/jira/browse/RANGER-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17015574#comment-17015574
]
Jiayi Liu edited comment on RANGER-2700 at 1/15/20 2:54 AM:
------------------------------------------------------------
Hi, [~vel]. Thank you for your reply, I create a review request in
https://reviews.apache.org/r/71998/, can you please help review?
was (Author: liujiayi771):
Hi, [~vel]. Thank you for your reply, I create a review request in
https://reviews.apache.org/r/71998/
> creating service sometimes fails because SecureRandom.getInstanceStrong() is
> often blocked
> ------------------------------------------------------------------------------------------
>
> Key: RANGER-2700
> URL: https://issues.apache.org/jira/browse/RANGER-2700
> Project: Ranger
> Issue Type: Improvement
> Components: admin
> Affects Versions: ranger-2.0
> Reporter: Jiayi Liu
> Priority: Major
> Attachments: 0001-RANGER-2700.patch
>
>
> I try to install ranger-2.0.0 on my cluster, however, I try to create a new
> service in Ranger WebUI, when I click the Add button, I keep stuck in the
> Please waiting state for a long time, and finally get an error that
> createService failed.
> I try to debug through the source code, and found that it stuck on
> generateBase64EncodedIV() in PasswordUtils.java. It uses
> SecureRandom.getInstanceStrong() to get the random string. We can find a lot
> of information showing that this function often blocks and is very slow.
> SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the
> thread if there isn't enough randomness available, but /dev/urandom will
> never block.
> SecureRandom.getInstanceStrong() is equivalent to
> SecureRandom.getInstance("NativePRNGBlocking"), so we can use /dev/urandom by
> replacing SecureRandom.getInstanceStrong().nextBytes(iv) with
> SecureRandom.getInstance("NativePRNGNonBlocking").nextBytes(iv) which will
> not be blocked, or we can use new SecureRandom().nextBytes(iv). /dev/random
> and /dev/urandom use the same pool of randomness under the hood, and they are
> equally secure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)