Hello all,
Another follow up on the same issue:
I have not yet set up a server on JDK8 but I have tried some other
variation to further narrow things down. Using
-Djdk.tls.client.protocols=TLSv1.2 on the client side of the
connection forces the use of TLSv1.2 (as opposed to 1.3 which is the
JDK11 default) and in that case everything works fine. The server
still uses 1.3 if available and therefore still fails for 1.3
clients at the same time. But the 1.2 clients work without issues.
My next try will be running the server with TLSv1.2 but I expect
that will simply suppress the issue for all clients.
I do not know if this is useful information at all. I have read
somewhere that the 1.3 code in JDK11 results in a different ordering
of some callbacks to the code managing server sockets but I have too
little experience there to make any educated guesses.
I will return soon with more information.
Kind regards,
Silvio
On 30-01-19 00:48, Silvio Bierman
wrote:
Hi Greg,
I just want to let you all know that I have reproduced the same
issue with a server running on Jetty 9.4.11.v20180605. I triggered
an SslContextFactory.reload on the server and immediately got the
same error on the client.
Since this version by far predates the first occurrence of the
issue on our servers I am now convinced this is something that was
introduced with our move from JDK10 (actually JDK11 early builds
on Ubuntu 18.04) to JDK11 (and Ubuntu 18.10) which coincided with
our move from Jetty 9.4.13 to 9.4.14. Now we know the Jetty
version is clearly not causing this it must be something related
to JDK11.
Since it is triggered by manipulating the server I am still
looking in that direction. My next step will be testing against a
server (with Jetty 9.4.14) running on JDK8. I will keep you
posted.
Kind regards,
Silvio
On 29-01-19 08:30, Greg Wilkins
wrote:
Silvio,
I am reading your emails... but so far I've had no
idea pop into my head.
The only thing I can think of is perhaps replacing
the SslContextFactory with exactly the code from 9.4.12
(I think 13 was a bad release for other reasons) and see
if that makes any difference. If it works, then you
could probably bisect the commits (only about 8 done
last year).
cheers
Hello all,
Another followup on the same topic: triggering a
SslContextFactory.reload on the server consistently and
immediately
triggers the problem on the client side, restarting the
server is close
to 100% (seems timing related). I was still leaning toward
something
fishy in the client code or even the JDK11 SSL client socket
code but
now I am almost certain this is going awry on the server
side.
Still JDK11 on both client and server side and Jetty
9.4.14.v20181114
server, using domain names that are covered by wildcard
certificates.
I am busy setting up a server with 9.4.11 and JDK8 to see
what happens
there but since I am packed it may take another week or so
to get results.
I will keep you posted.
>> One addition: this morning I replaced the keystore
file on one of the
>> servers because some almost-expired certificates
had been updated and
>> subsequently triggered a SslContextFactory.reload
through the
>> application. Within 15 minutes the logging showed
about two dozen
>> failed requests. Then it silently went away. May be
a coincidence of
>> course.
>>
>> Silvio
>>
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
--
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
|