[ 
https://issues.apache.org/jira/browse/SOLR-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15976243#comment-15976243
 ] 

Mihaly Toth commented on SOLR-10338:
------------------------------------

Even though generating a random number is pretty fast in case it is 
nonblocking... but I agree that the tests would be more deterministic with just 
checking the algorithm, and less prone to timing issues. So lets do that.

An additional enhancement proposed by [~manokovacs] is to try to set 
{{java.security.egd}} if it is unset. This would try to set the algorithm to 
non blocking on a best effort basis. Like:
{code}
    if (null == allowed) {
      if(egdfile == null)
        System.setProperty("java.security.egd", "file:/dev/./urandom");
      else
        assertEquals("Solr tests expect a non-blocking SecureRandom to be 
configured. " +
                     "Use -Djava.security.egd=file:/dev/./urandom as a JVM 
option when running tests to bypass this check.",
            "file:/dev/./urandom", egdfile);
    }
{code}

What do you think?


> Configure SecureRandom non blocking for tests.
> ----------------------------------------------
>
>                 Key: SOLR-10338
>                 URL: https://issues.apache.org/jira/browse/SOLR-10338
>             Project: Solr
>          Issue Type: Sub-task
>            Reporter: Mihaly Toth
>            Assignee: Mark Miller
>             Fix For: 6.6, master (7.0)
>
>         Attachments: SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, 
> SOLR-10338.patch
>
>
> It would be best if SecureRandom could be made non blocking. In that case we 
> could get rid of random entropy exhaustion issue related to all usages of 
> SecureRandom.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to