[
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: [email protected]
For additional commands, e-mail: [email protected]
