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:
    if (null == allowed) {
      if(egdfile == null)
        System.setProperty("java.security.egd", "file:/dev/./urandom");
        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);

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

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

Reply via email to