[
https://issues.apache.org/jira/browse/SOLR-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16867933#comment-16867933
]
Hoss Man commented on SOLR-12988:
---------------------------------
bq. Firstly, I don't see any problem with compiling branch_8x on java8 locally.
That's very suprising since java.lang.Runtime.Version didn't exist until
java9...
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/732/
(and locally for me running w/ java8, java11, etc...)
{noformat}
[javac] Compiling 55 source files to
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build/solr-test-framework/classes/java
[javac]
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:108:
error: cannot
find symbol
[javac] if (Constants.JRE_IS_MINIMUM_JAVA11 &&
Runtime.version().compareTo(Runtime.Version.parse("11.0.3")) < 0) {
[javac] ^
[javac] symbol: method version()
[javac] location: class Runtime
[javac]
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:108:
error: cannot
find symbol
[javac] if (Constants.JRE_IS_MINIMUM_JAVA11 &&
Runtime.version().compareTo(Runtime.Version.parse("11.0.3")) < 0) {
[javac]
^
[javac] symbol: variable Version
[javac] location: class Runtime
{noformat}
bq. Secondly, I rushed the commit to revert changes back to it used to be +
minimal checks so Jenkins will become happy. ...
No, you didn't "revert" anything back to "minimal checks" ... you "fixed
forward" to *different* checks. That's not the same as "reverting" to what we
had before: which was a known and relatively stable state.
We're talking about very fundemental changes to test infrastructure that impact
over a thousand tests -- we should be hammering on these locally for a *LONG*
time, with differnet JVMs, on both branches, before pushing forward any changes
-- and as i've suggested repeatedly: we should not push *ANY* serious changes
-- particularly jvm version dependent behavior cahnages -- until the jenkins
boxes are running 11.0.3, so _they_ are ready to hammer on whatever changes we
commit, in case there are *OTHER* SSL bugs we haven't found or considered yet.
Even if we have rock solid "don't use ssl unless 11.0.3" logic in our tests,
that's a potential time bomb that might go off w/some unknown bug once jenkins
is upgraded -- we shouldn't just leave that in our code waiting to see what
happens if/when you or I are offline for an extended period of time when
jenkins gets upgraded.
bq. ...does that most recent patch matched to your idea?
Well, besides the fact that it still uses Runtime.Version (so won't compile on
branch_8x) i guess it's ok? but i'm still a little worried about having it only
be conditional on the java versoin and not on the JVM impl...
bq. ...that could still lead to weird situations if/when people use non-OpenJDK
based JVMs, or potentially use their own builds of Open-JDK that they've
patched, etc...
Ideally i'd much rather have have a quick and dirty helper method we could use
to ask "does this jvm manifest this bug", that actually uses the SSLEngine to
see if these bugs get triggered -- but that's fairly non trivial, so i guess
just checking the version info is fine (although i think we should almost
certainly be checking the java vendor in addition to the java version)
----
But to re-iterate: even if/once we have a "good" patch (that can be backported
to 8x) i *STILL* think we need to revert all of these changes, and not move
forward with any patch (or existing changes to allow SSL testing on java11)
until the jenkins boxes are running 11.0.3.
> 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-12988.patch, 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]
