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