[GitHub] [solr] dweiss commented on a change in pull request #214: SOLR-15428: Integrate the OpenJDK JMH micro benchmark framework for m…

[GitBox <gi...@apache.org>]

dweiss commented on a change in pull request #214:
URL: https://github.com/apache/solr/pull/214#discussion_r681624518



##########
File path: solr/test-framework/src/java/org/apache/solr/util/RandomizeSSL.java
##########
@@ -104,10 +105,10 @@ public SSLRandomizer(double ssl, double clientAuth, String debug) {
     public SSLTestConfig createSSLTestConfig() {
       // even if we know SSL is disabled, always consume the same amount of randomness
       // that way all other test behavior should be consistent even if a user adds/removes @SuppressSSL
-      
-      final boolean useSSL = TestUtil.nextInt(LuceneTestCase.random(), 0, 999) <
+      Random random = new Random();

Review comment:
       My thought is that if you use independently initialized randoms then the entire concept of randomized testing fails - you won't be able to reproduce your issues. Random isn't really gone. ThreadLocalRandom is a Random. SplittableRandom isn't, but you could make a delegate if needed. 
   
   Also, as I many times pointed out, if performance is the key, use any random implementation you wish but start from the framework's-provided initial seed. Then you can hope for reproducible behavior but at the same time have a faster random seed generator where it's needed.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org