[jira] [Commented] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2

Igor Motov (Jira)

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

Hoss Man commented on SOLR-12988:
---------------------------------

Here's what i think...
 # You should revert *EVERYTHING* you've commited to this issue – including your most recent commit to branch_8x *that doesn't even fucking compile with java8 !*
 # We should wait for Uwe to have a chance to see & respond to my email requesting that jenkins be upgrade to 11.0.3 (it's only been 1 day)
 # You should slow WAAAAAAAY down on things, and stop rushing to commit things. Twice now you've asked me my opinion (w/o even posting a patch showing exactly what your suggestion was) and then rushed to commit changes (the first time only 2 hours later, the second 10 minutes later ... both while i was asleep) ... apparently w/o even checking to see if it compiled first!  if you want opinions on your ideas give people time to (wake up and) think about it, other wise why bother asking?
 # Once Jenkins is running 11.0.3, *THEN* we should do the bare minimum to re-enable SSL testing, and wait until we see lots and lots of jenkins builds, running 11.0.3, to confirm there aren't any *other* SSL problems, before we make any other decisions about changes to either the Runtime behavior of solr, or to the tests.

{quote}But I kinda wondering what we should do with the tests? Should we enforce tests to run in TLSv1.2 for 11 to 11.02? Since not all developers - jenkins do know this and do the upgrade their sdk?
{quote}
I already shared my thoughts on this...
{quote}Fundementally i think it's a very bad idea to have Solr's behavior radically change based on introspection of the JVM details – it makes it very hard to test/reproduce problems. I think it makes a lot more sense for solr to simply log "Your JVM is known to have some problems, see URL for details" and let the failures happen if they are going to happen. ...
{quote}
if devs are running tests with a broken JVM, then the tests can & should fail ... that's the job of the tests. it's a bad idea to make the tests "hide" the failure by "faking" that things work using a degraded cipher, or skipping SSL completely (yes, i also think mark's changes to SSLTestConfig in December as part of his commit on this issue was a terrible idea as well) ... the *ONLY* thing we should _consider_ allowing tests to change about their behavior if they see a JVM is "broken" is to {{SKIP}} ie: assume(SomethingThatIsFalseForTheBrokenJVM) ...
{quote}(on the Junit tests side, having assumes around JVM version is fine – because even then it's not a "silent" behavior change, it's an explicitly "test ignored because XYZ")
{quote}
...fundementally, this psuedo-code (which mark added to SSLTestConfig in december and still exists in a slightly diff form in your latest commit) should *NOT* exist anywhere in our test scaffolding...
{code:java}
if (testOrRandomizationWantsSSL && isCurrentJVMBrokenWithSSL()) {
  testOrRandomizationWantsSSL = false;
}
{code}
instead, it should be...
{code:java}
if (testOrRandomizationWantsSSL) {
  assumeFalse("Test (or randomization) wants to use SSL for this seed, " +
              "but SSL is known to fail on your JVM", isCurrentJVMBrokenWithSSL());
}
{code}
Saying "we're going to have our this silently use TLSv1.2 (or skip SSL) on your JVM because it's broken even though that's not what would happen if you tried to actually run solr on ths broken JVM" is the absolute worst possible thing we can do.

> Skip running tests with SSL on Java 11 to 11.0.2
> ------------------------------------------------
>
>                 Key: SOLR-12988
>                 URL: https://issues.apache.org/jira/browse/SOLR-12988
>             Project: Solr
>          Issue Type: Test
>            Reporter: Hoss Man
>            Assignee: Cao Manh Dat
>            Priority: Major
>              Labels: Java11, Java12
>         Attachments: SOLR-13413.patch
>
>
> HTTPCLIENT-1967 indicates that HttpClient can't be used properly with TLSv1.3. It caused some test failures below, therefore we should skip running tests with SSL on Java 11 to 11.0.2.
> TestMiniSolrCloudClusterSSL.testSslWithCheckPeerName seems to fail 100% of the time when run with java11 (or java12), regardless of seed, on both master & 7x.
> The nature of the problem and the way our htp stack works suggests it *may* ultimately be a jetty bug (perhaps related to [jetty issue#2711|https://github.com/eclipse/jetty.project/issues/2711]?)
> *HOWEVER* ... as far as i can tell, whatever the root cause is, seems to have been fixed on the {{jira/http2}} branch (as of 52bc163dc1804c31af09c1fba99647005da415ad) which should hopefully be getting merged to master soon.
> Filing this issue largely for tracking purpose, although we may also want to use it for discussions/considerations of other backports/fixes to 7x



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]