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

["Steve Rowe (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289889#comment-15289889 ] 

Steve Rowe commented on SOLR-9107:
----------------------------------

+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? 

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

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.

-----

{code:java|title=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);
{code}

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]):

{code:java}
      final RandomizeSSL annotation = clazz.<RandomizeSSL>getAnnotation(RandomizeSSL.class);
{code}


> 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
>             Fix For: 4.9, 6.0
>
>         Attachments: 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