You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Steve Rowe (JIRA)" <ji...@apache.org> on 2016/06/08 17:30:21 UTC

[jira] [Reopened] (SOLR-9107) add annotation for more fine grained control of SSL per test-class

     [ https://issues.apache.org/jira/browse/SOLR-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Rowe reopened SOLR-9107:
------------------------------

My Jenkins found a reproducing seed for a {{TestSSLRandomization.testSslRandomizer()}} failure:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestSSLRandomization -Dtests.method=testSSLRandomizer -Dtests.seed=2E775F0292A463C2 -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt -Dtests.locale=en-PH -Dtests.timezone=Africa/Blantyre -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 0.05s J1  | TestSSLRandomization.testSSLRandomizer <<<
   [junit4]    > Throwable #1: java.lang.AssertionError: expected:<true> but was:<false>
   [junit4]    > 	at __randomizedtesting.SeedInfo.seed([2E775F0292A463C2:84FFA6FD36CC78D6]:0)
   [junit4]    > 	at org.apache.solr.cloud.TestSSLRandomization.testSSLRandomizer(TestSSLRandomization.java:199)
{noformat}

{code:java|title=TestSSLRandomization.testSSLRandomizer()}
195: r = SSLRandomizer.getSSLRandomizerForClass(MaxAnnotated.class);
196: assertEquals(1.0D, r.ssl, 0.0D);
197: assertEquals(1.0D, r.clientAuth, 0.0D);
198: conf = r.createSSLTestConfig();
199: assertEquals(true, conf.isSSLMode());
200: assertEquals(true, conf.isClientAuthMode());
{code}

{code:java|title=RandomizeSSL.SSLRandomizer}
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, 1000) < 
    (int)(1000 * getEffectiveOdds(ssl, LuceneTestCase.TEST_NIGHTLY, LuceneTestCase.RANDOM_MULTIPLIER));
  final boolean useClientAuth = TestUtil.nextInt(LuceneTestCase.random(), 0, 1000) < 
    (int)(1000 * getEffectiveOdds(clientAuth, LuceneTestCase.TEST_NIGHTLY, LuceneTestCase.RANDOM_MULTIPLIER));

  return new SSLTestConfig(useSSL, useClientAuth);
}
{code}
With the above seed {{TestUtil.nextInt()}} produces the top of the range (1000), and so {{useSSL}} is set to {{false}}, since {{1000}} is not less than {{1000 * the effective odds (1.0)}}.

One way to fix this is to reduce the top of the range of random ints from 1000 to 999, so that effective 100% odds are never randomly trumped.

I believe that the inverse is not a problem currently or with my proposed fix: when the effective odds are {{0.0}}, if the next random int happens to be {{0}}, {{0 < 0}} will evaluate to {{false}}.

The {{useClientAuth}} calculation will also need the same fix.

> add annotation for more fine grained control of SSL per test-class
> ------------------------------------------------------------------
>
>                 Key: SOLR-9107
>                 URL: https://issues.apache.org/jira/browse/SOLR-9107
>             Project: Solr
>          Issue Type: Sub-task
>            Reporter: Hoss Man
>            Assignee: Hoss Man
>             Fix For: 6.1, master (7.0)
>
>         Attachments: SOLR-9107.patch, SOLR-9107.patch
>
>
> Spinning off this idea from my earlier comment in SOLR-5776...
> ----
> At some point in the future, after all this soaks, we should consider increasing the odds of using SSL – perhaps even add a new annotation (or replace @SupressSSL) with a param to help control the odds of using SSL / clientAuth on a per-class basis, ie...
> {noformat}
>   @UseSSL(false) // same as @SupressSSL
>   @UseSSL() //  same as default if no annotation: SolrTestCaseJ4 picks SSL / clientAuth using LuceneTestCase.rarely
>   @UseSSL(ssl=0.75,clientAuth=0.25) // fine control of odds of using ssl & clientauth
> {noformat}
> ...some tests, like TestSSLRandomization should ideally have much higher odds of using SSL then other tests, and if we had an easy way to say "these handful of simple cloud tests should use SSL very frequently" then it wouldn't matter so much if the odds of other really 'expensive' tests only use SSL once in a blue moon.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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