Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.1, 7.0
    • Component/s: None
    • Labels:
      None

      Description

      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...

        @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
      

      ...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.

      1. SOLR-9107.patch
        20 kB
        Hoss Man
      2. SOLR-9107.patch
        18 kB
        Hoss Man

        Issue Links

          Activity

          Hide
          hossman Hoss Man added a comment -

          i've tweaked the syntax a bit from my original comment (@RandomizeSSL(0.0) instead of @RandomizeSSL(false) so it plays more nicely with things like @RandomizeSSL(1.0)) but here's a patch that is pretty close to what i described before.

          you can still use @SuppressSSL of course, or provide a single double value to control the odds of both SSL and clientAuth – ie: @RandomizeSSL(0.5) for 50% chance (clientAuth still calculated independently) or go whole hog and say things like "I want SSL to always be used, but clientAuth should never be used" via @RandomizeSSL(ssl=1.0,clientAuth=0.0)

          This also increases the "effective odds" of both SSL and clientAuth based on test.nightly and the value of the test.multiplier (starting with the "configured odds")

          at present, the "sensible default" when no odds are explicitly configured is still 20% of the time (which can wind up being higher with nightly/multiplier), but i think we could easily decrease that default to 10% or even 5% (to speed up typical test runs) if we move forward with adding this annotation (using high configured values) to some of the more critical (and short) cloud tests that we really want to use SSL frequently. LIkewise, some of the existing @SuppressSSL tests could probably be switched to something like @RandomizeSSL(0.01) so they can still get tested with SSL occasionally

          Mark Miller – what do you think?

          Show
          hossman Hoss Man added a comment - i've tweaked the syntax a bit from my original comment ( @RandomizeSSL(0.0) instead of @RandomizeSSL(false) so it plays more nicely with things like @RandomizeSSL(1.0) ) but here's a patch that is pretty close to what i described before. you can still use @SuppressSSL of course, or provide a single double value to control the odds of both SSL and clientAuth – ie: @RandomizeSSL(0.5) for 50% chance (clientAuth still calculated independently) or go whole hog and say things like "I want SSL to always be used, but clientAuth should never be used" via @RandomizeSSL(ssl=1.0,clientAuth=0.0) This also increases the "effective odds" of both SSL and clientAuth based on test.nightly and the value of the test.multiplier (starting with the "configured odds") at present, the "sensible default" when no odds are explicitly configured is still 20% of the time (which can wind up being higher with nightly/multiplier), but i think we could easily decrease that default to 10% or even 5% (to speed up typical test runs) if we move forward with adding this annotation (using high configured values) to some of the more critical (and short) cloud tests that we really want to use SSL frequently. LIkewise, some of the existing @SuppressSSL tests could probably be switched to something like @RandomizeSSL(0.01) so they can still get tested with SSL occasionally Mark Miller – what do you think?
          Hide
          steve_rowe Steve Rowe added a comment -

          +1 overall, all Solr tests passed for me on Linux and OS X (modulo a couple that fail intermittently without this patch too).

          On SSL usage probabilities: nice folding in of tests.nightly (though the ~10% greater likelihood in your patch seems a little low) and tests.multiplier (taking the log means the default multiplier of 1 won't change the declared odds, since ln(1)=0).


          Since the method below is only ever called from SolrTestCaseJ4.beforeClass(), and all SolrTestCaseJ4 subclasses will inherit its @RandomizeSSL (or override it with their own), annotation in the code below will never be null, I think? I guess this handles the case of third-party usage when not extending SolrTestCaseJ4?

          From RandomizeSSL.getSSLRandomizerForClass(Class)
                if (null == annotation) {
                  return new SSLRandomizer(0.0D, 0.0D, RandomizeSSL.class.getName() + " annotation not specified");
                }
          

          I see TestSSLRandomization.testSSLRandomizer() mostly tests classes that don't inherit from an annotated class, but that's zero actual Solr test cases, right? I think more testing of the inheriting cases is warranted.


          From RandomizeSSL.getSSLRandomizerForClass(Class):
                // nocommit: WTF won't this compile w/o casting???
                //final RandomizeSSL annotation = clazz.getAnnotation(RandomizeSSL.class);
                final RandomizeSSL annotation = (RandomizeSSL) clazz.getAnnotation(RandomizeSSL.class);
          

          Type erasure is a runtime thing, so I'm not sure why the compiler doesn't like it.

          The following works, and is maybe a clue about what's happening, but isn't really better than casting (from one of the answers here: http://stackoverflow.com/questions/450807/how-do-i-make-the-method-return-type-generic):

                final RandomizeSSL annotation = clazz.<RandomizeSSL>getAnnotation(RandomizeSSL.class);
          
          Show
          steve_rowe Steve Rowe added a comment - +1 overall, all Solr tests passed for me on Linux and OS X (modulo a couple that fail intermittently without this patch too). On SSL usage probabilities: nice folding in of tests.nightly (though the ~10% greater likelihood in your patch seems a little low) and tests.multiplier (taking the log means the default multiplier of 1 won't change the declared odds, since ln(1)=0). Since the method below is only ever called from SolrTestCaseJ4.beforeClass(), and all SolrTestCaseJ4 subclasses will inherit its @RandomizeSSL (or override it with their own), annotation in the code below will never be null, I think? I guess this handles the case of third-party usage when not extending SolrTestCaseJ4? From RandomizeSSL.getSSLRandomizerForClass(Class) if ( null == annotation) { return new SSLRandomizer(0.0D, 0.0D, RandomizeSSL.class.getName() + " annotation not specified" ); } I see TestSSLRandomization.testSSLRandomizer() mostly tests classes that don't inherit from an annotated class, but that's zero actual Solr test cases, right? I think more testing of the inheriting cases is warranted. From RandomizeSSL.getSSLRandomizerForClass(Class): // nocommit: WTF won't this compile w/o casting??? // final RandomizeSSL annotation = clazz.getAnnotation(RandomizeSSL.class); final RandomizeSSL annotation = (RandomizeSSL) clazz.getAnnotation(RandomizeSSL.class); Type erasure is a runtime thing, so I'm not sure why the compiler doesn't like it. The following works, and is maybe a clue about what's happening, but isn't really better than casting (from one of the answers here: http://stackoverflow.com/questions/450807/how-do-i-make-the-method-return-type-generic ): final RandomizeSSL annotation = clazz.<RandomizeSSL>getAnnotation(RandomizeSSL.class);
          Hide
          hossman Hoss Man added a comment -

          (though the ~10% greater likelihood in your patch seems a little low)

          I'm trying to keep things a bit conservative for now ... i don't want to cause the runtime of jenkins nightly builds to explode. It can always be increased later.

          ... I guess this handles the case of third-party usage when not extending SolrTestCaseJ4?

          yeah, i'm mainly just trying to be paranoid here – like "what if someone (solr committer or third party dev) writes a new test baseclass that doesn't subclass SolrTestCaseJ4 and tries to use getSSLRandomizerForClass w/o realizing it's only for classes w/that annotation?" or "what if we decide not all tests should use SSL implicitly and remove the anotation from SolrTestCaseJ4 in the future?"

          I see TestSSLRandomization.testSSLRandomizer() ... I think more testing of the inheriting cases is warranted.

          Good point.

          The following works, ...

          Not for me it didn't...

              [javac] /home/hossman/lucene/dev/solr/test-framework/src/java/org/apache/solr/util/RandomizeSSL.java:153: error: incompatible types: Annotation cannot be converted to RandomizeSSL
              [javac]       final RandomizeSSL annotation = clazz.<RandomizeSSL>getAnnotation(RandomizeSSL.class);
          

          ...but like you said, not really any cleaner then casting, and i don't really care enough to waste more time on figuring out why it doesn't work.


          Updated patch:

          • fixes the last few nocommits (SuppressSSL now reports the bugUrl in the logs)
          • improves testing of the various inheritence situations
          • add a comment clarifying to future devs readng the code why an inherited SuppressSSL should override a direct RandomzeSSL annotation.
          • at some multiplier randomization to the "always" and "never ever" checks in testSSLRandomizerEffectiveOdds to ensure we always do the right thing no matter how crazy the test runner might be

          I'm pretty happy with how things are, and would like to commit soon – but as things stand with this patch, precommit currently complains about malformed javadocs...

               [echo] Checking for malformed docs...
               [exec] 
               [exec] /home/hossman/lucene/dev/solr/build/docs/solr-test-framework/org/apache/solr/util/RandomizeSSL.html
               [exec]   broken details HTML: Field Detail: reason: saw closing "</ul>" without opening <ul...>
               [exec]   broken details HTML: Field Detail: ssl: saw closing "</ul>" without opening <ul...>
               [exec]   broken details HTML: Field Detail: clientAuth: saw closing "</ul>" without opening <ul...>
          

          ...but i can't really understand why. The <ul> tags look balanced to me, and tidy -output /dev/null .../RandomizeSSL.html concurs that "No warnings or errors were found." I thought maybe the problem was related to some of the @see tags in the docs for these attributes, but even if i completley remove the javadocs the same validation errors occur.

          Anybody have any idea what's going on here? Steve Rowe? Uwe Schindler?

          Show
          hossman Hoss Man added a comment - (though the ~10% greater likelihood in your patch seems a little low) I'm trying to keep things a bit conservative for now ... i don't want to cause the runtime of jenkins nightly builds to explode. It can always be increased later. ... I guess this handles the case of third-party usage when not extending SolrTestCaseJ4? yeah, i'm mainly just trying to be paranoid here – like "what if someone (solr committer or third party dev) writes a new test baseclass that doesn't subclass SolrTestCaseJ4 and tries to use getSSLRandomizerForClass w/o realizing it's only for classes w/that annotation?" or "what if we decide not all tests should use SSL implicitly and remove the anotation from SolrTestCaseJ4 in the future?" I see TestSSLRandomization.testSSLRandomizer() ... I think more testing of the inheriting cases is warranted. Good point. The following works, ... Not for me it didn't... [javac] /home/hossman/lucene/dev/solr/test-framework/src/java/org/apache/solr/util/RandomizeSSL.java:153: error: incompatible types: Annotation cannot be converted to RandomizeSSL [javac] final RandomizeSSL annotation = clazz.<RandomizeSSL>getAnnotation(RandomizeSSL.class); ...but like you said, not really any cleaner then casting, and i don't really care enough to waste more time on figuring out why it doesn't work. Updated patch: fixes the last few nocommits (SuppressSSL now reports the bugUrl in the logs) improves testing of the various inheritence situations add a comment clarifying to future devs readng the code why an inherited SuppressSSL should override a direct RandomzeSSL annotation. at some multiplier randomization to the "always" and "never ever" checks in testSSLRandomizerEffectiveOdds to ensure we always do the right thing no matter how crazy the test runner might be I'm pretty happy with how things are, and would like to commit soon – but as things stand with this patch, precommit currently complains about malformed javadocs... [echo] Checking for malformed docs... [exec] [exec] /home/hossman/lucene/dev/solr/build/docs/solr-test-framework/org/apache/solr/util/RandomizeSSL.html [exec] broken details HTML: Field Detail: reason: saw closing "</ul>" without opening <ul...> [exec] broken details HTML: Field Detail: ssl: saw closing "</ul>" without opening <ul...> [exec] broken details HTML: Field Detail: clientAuth: saw closing "</ul>" without opening <ul...> ...but i can't really understand why. The <ul> tags look balanced to me, and tidy -output /dev/null .../RandomizeSSL.html concurs that "No warnings or errors were found." I thought maybe the problem was related to some of the @see tags in the docs for these attributes, but even if i completley remove the javadocs the same validation errors occur. Anybody have any idea what's going on here? Steve Rowe ? Uwe Schindler ?
          Hide
          steve_rowe Steve Rowe added a comment -

          precommit currently complains about malformed javadocs... [...] Anybody have any idea what's going on here? Steve Rowe? Uwe Schindler?

          See LUCENE-7308

          Show
          steve_rowe Steve Rowe added a comment - precommit currently complains about malformed javadocs... [...] Anybody have any idea what's going on here? Steve Rowe? Uwe Schindler? See LUCENE-7308
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 09372acb660d21b6da01f6ea65f00493126ee32b in lucene-solr's branch refs/heads/master from Chris Hostetter
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=09372ac ]

          SOLR-9107: new @RandomizeSSL annotation for more fine grained control of SSL testing

          Show
          jira-bot ASF subversion and git services added a comment - Commit 09372acb660d21b6da01f6ea65f00493126ee32b in lucene-solr's branch refs/heads/master from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=09372ac ] SOLR-9107 : new @RandomizeSSL annotation for more fine grained control of SSL testing
          Hide
          hossman Hoss Man added a comment -

          ill let this sit on master for at least a day before pushing to 6x

          Show
          hossman Hoss Man added a comment - ill let this sit on master for at least a day before pushing to 6x
          Hide
          hossman Hoss Man added a comment - - edited

          FYI: the increased odds ot using SSL in nightly / with tests.multiplier have helped uncover some OOM issues in tests when using SSL, see SOLR-9182

          (edit: typo in linked issue #)

          Show
          hossman Hoss Man added a comment - - edited FYI: the increased odds ot using SSL in nightly / with tests.multiplier have helped uncover some OOM issues in tests when using SSL, see SOLR-9182 (edit: typo in linked issue #)
          Hide
          jira-bot ASF subversion and git services added a comment - - edited


          EDIT: Typo Commit Msg for SOLR-9081

          Show
          jira-bot ASF subversion and git services added a comment - - edited EDIT: Typo Commit Msg for SOLR-9081
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 8481d6f47fdcbbae049d07aa810c9632f44c201b in lucene-solr's branch refs/heads/branch_6x from Chris Hostetter
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8481d6f ]

          SOLR-9107: new @RandomizeSSL annotation for more fine grained control of SSL testing

          (cherry picked from commit 09372acb660d21b6da01f6ea65f00493126ee32b)

          Conflicts:
          solr/CHANGES.txt

          Show
          jira-bot ASF subversion and git services added a comment - Commit 8481d6f47fdcbbae049d07aa810c9632f44c201b in lucene-solr's branch refs/heads/branch_6x from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8481d6f ] SOLR-9107 : new @RandomizeSSL annotation for more fine grained control of SSL testing (cherry picked from commit 09372acb660d21b6da01f6ea65f00493126ee32b) Conflicts: solr/CHANGES.txt
          Hide
          steve_rowe Steve Rowe added a comment -

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

             [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)
          
          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());
          
          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);
          }
          

          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.

          Show
          steve_rowe Steve Rowe added a comment - My Jenkins found a reproducing seed for a TestSSLRandomization.testSslRandomizer() failure: [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) 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()); 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); } 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.
          Hide
          steve_rowe Steve Rowe added a comment -

          Hoss told me offline that my proposed fix sounds fine on cursory inspection, so I'll commit it shortly.

          Show
          steve_rowe Steve Rowe added a comment - Hoss told me offline that my proposed fix sounds fine on cursory inspection, so I'll commit it shortly.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 86c053dd1055c5b2b4cfe3c8e6b573d3d1272b24 in lucene-solr's branch refs/heads/master from Steve Rowe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=86c053d ]

          SOLR-9107: When creating a randomized SSL test config, 100% effective odds of using SSL and/or client auth should never be trumped by chance.

          Show
          jira-bot ASF subversion and git services added a comment - Commit 86c053dd1055c5b2b4cfe3c8e6b573d3d1272b24 in lucene-solr's branch refs/heads/master from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=86c053d ] SOLR-9107 : When creating a randomized SSL test config, 100% effective odds of using SSL and/or client auth should never be trumped by chance.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit eebce4a406716c1e1f31dd77a8d184d6e910df96 in lucene-solr's branch refs/heads/branch_6_1 from Steve Rowe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eebce4a ]

          SOLR-9107: When creating a randomized SSL test config, 100% effective odds of using SSL and/or client auth should never be trumped by chance.

          Show
          jira-bot ASF subversion and git services added a comment - Commit eebce4a406716c1e1f31dd77a8d184d6e910df96 in lucene-solr's branch refs/heads/branch_6_1 from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eebce4a ] SOLR-9107 : When creating a randomized SSL test config, 100% effective odds of using SSL and/or client auth should never be trumped by chance.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit ded16f8f182c6527df1ea15830d65815227aed25 in lucene-solr's branch refs/heads/branch_6x from Steve Rowe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ded16f8 ]

          SOLR-9107: When creating a randomized SSL test config, 100% effective odds of using SSL and/or client auth should never be trumped by chance.

          Show
          jira-bot ASF subversion and git services added a comment - Commit ded16f8f182c6527df1ea15830d65815227aed25 in lucene-solr's branch refs/heads/branch_6x from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ded16f8 ] SOLR-9107 : When creating a randomized SSL test config, 100% effective odds of using SSL and/or client auth should never be trumped by chance.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 86c053dd1055c5b2b4cfe3c8e6b573d3d1272b24 in lucene-solr's branch refs/heads/SOLR-9191 from Steve Rowe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=86c053d ]

          SOLR-9107: When creating a randomized SSL test config, 100% effective odds of using SSL and/or client auth should never be trumped by chance.

          Show
          jira-bot ASF subversion and git services added a comment - Commit 86c053dd1055c5b2b4cfe3c8e6b573d3d1272b24 in lucene-solr's branch refs/heads/ SOLR-9191 from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=86c053d ] SOLR-9107 : When creating a randomized SSL test config, 100% effective odds of using SSL and/or client auth should never be trumped by chance.

            People

            • Assignee:
              hossman Hoss Man
              Reporter:
              hossman Hoss Man
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development