Open mbien opened 10 months ago
found
System.setProperty("javax.net.debug", "ssl:handshake");
to be useful for SSL debugging. But it produces a lot of output with is mixed with the test output which is also a lot. Would be interesting to diff the two https handshake logs of the gradle Downloader
with and without the workaround.
exception snippet taken from the PR:
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:347)
at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293)
at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:186)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1511)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1421)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:456)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:427)
at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:580)
at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:201)
at java.base/sun.net.www.protocol.http.HttpURLConnection.followRedirect0(HttpURLConnection.java:2830)
at java.base/sun.net.www.protocol.http.HttpURLConnection.followRedirect(HttpURLConnection.java:2742)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1869)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1525)
at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:250)
at org.gradle.wrapper.Download.downloadInternal(Download.java:129)
at org.gradle.wrapper.Download.download(Download.java:109)
we can probably revert this now again. The problem seems to have some self healing properties as suspected ;)
I repeated some brute force testing in my clone to exclude that this has something to do with an JDK update release:
And since we already excluded before that it is os image related in any way (the image hash didn't change between the last good and the first bad run), it likely is nw infra related. Since I also could reproduce it locally back then, it likely was the gradle host config since this would exclude CI too.
cc @sdedic
sorry about the noise, I ran the wrong tests and got excited too fast.
The problem will likely resolve itself (due to updates in tested gradle versions or other means), once it is working again, remove the workaround added in #6673
See first
//TODO
inMicronautGradleArtifactsImplTest
andProjectViewTest
(c0f09c927b7a63ebc228156afc8e2ff35ec34b84)