lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Commented] (SOLR-12988) Skip running tests with SSL on Java 11 to 11.0.2
Date Wed, 19 Jun 2019 17:46:00 GMT


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?
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. ...
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")
...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
if (testOrRandomizationWantsSSL && isCurrentJVMBrokenWithSSL()) {
  testOrRandomizationWantsSSL = false;
instead, it should be...
if (testOrRandomizationWantsSSL) {
  assumeFalse("Test (or randomization) wants to use SSL for this seed, " +
              "but SSL is known to fail on your JVM", isCurrentJVMBrokenWithSSL());
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:
>             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|]?)
> *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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message