Hi Erick, according to Jetty release logs: For Java 11 support, Jetty should be updated to latest version released this November: 9.4.14 - which we have already done in master (not sure about 7.x). Unfortunately the release candidate of 7.6 is on Jetty 9.4.11 which has no Java 11 support for TLS 1.3 at all. IMHO, we should update this ASAP, but this only affects support for TLS 1.3 - so it's more a security fix.
>From what I see, the issues are more test issues because it happens randomly >like "no live nodes available, connection timed out /...." I think the issues >here is that timing slightly changed, so tests fail more often (there seems to >be the problem that tests don't really get the correct time when "jetty has >fully started and accepts connections" - this is at least how it was explained >to me on berlinbuzzwords). Depending on timing (e.g, Jetty is slow in starting >up, it's hammered with requests already). The new TLS functionality in JDK 11 >seem to slow down startup times - no idea. Maybe Mark Miller can explain >better what's sometimes wrong with timing. The previous statement can be >nonsense at all, it was just my understanding when talking with other >committers on berlinbuzzwords. But the test failures seemed to happen inside HttpClient. So not only the server can be the problem, maybe it's the client, too. I can say: those issues do not happen in production, I had no problem to connect to a jetty server with standard TLS browser on Java 11. The HTTP2 branch has some problems, but when tests pass it almost 100% and it looks much more stable. Recently we just had some other test problems regarding "what HTTP version randomly to support". Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Erick Erickson <[email protected]> > Sent: Wednesday, December 12, 2018 1:45 AM > To: [email protected] > Subject: Re: Java 11. > > Well, you've done a lot more thorough testing of the different > versions of Java than I have. I regularly see many more tests failing > that have JDK11 in the title, but perhaps it's all the TLS stuff. > > bq. ...think, if you want to use SSL/TLS, the status in Java 11 is undefined > > This is a pretty important caveat, I have numerous clients that insist > on TLS. So are you saying that this problem is in the _tests_ or > enabling SSL/TLS with JDK11 in general? > On Tue, Dec 11, 2018 at 3:57 PM Uwe Schindler <[email protected]> wrote: > > > > Hi Erick, > > > > > I just noticed that Solr's CHANGES.txt has this at the beginning: > > > > > > You need a Java 1.8 VM or later installed. > > > > > > Is this still what we want to say between now and whenever we > > > understand the various failures on jdk 9, 10, 11 and 12? Do we want to > > > specifically say that 9 and 10 are not recommended? > > > > I think, if you want to use SSL/TLS, the status in Java 11 is undefined. The > error rate with Java 11 is higher than with Java 8 to Java 10 (because of > support for TLS 1.3 which seem to cause some SSL-related tests to fail). But > standard Solr usage is perfectly possible with Java 8 to 11 and actually some > of my customers (none of them uses SSL) have already changed without any > problems. > > > > As far as I see, the HTTP2 branch is also in a good shape (with Java 11), so > the statement in the CHANGES.txt and SYSTEM_REQUIREMENTS.txt is in > perfect shape. No idea what you are talking about? Why do you think that > Java 9 or 10 does not work? > > > > On my machines, Smoke tester on Policeman running with Java 9 finished > on the first run (it ran tests with both Java 8 and Java 9). SUCCESS! > > > > The issues with tests is less Java version than more flakey tests. I cannot > see any significance depending on Java version - sorry! > > > > Uwe > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
