ConnectionShutdownException in Maven plugin with Java 8 Update 252

Hi,

the project I am working in uses the Sonar Maven Plugin to scan Java code and upload the results to the SonarQube server.
A few days ago this stopped working, suddenly we were getting this error:

[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.7.0.1746:sonar (default-cli) on project portals-workspace: Unable to execute SonarQube: Fail to get bootstrap index from server: ConnectionShutdownException -> [Help 1]

The SonarQube server is running version 7.9.2 (build 30863), no changes have been done there for weeks. But what changed recently is the Java version on the client side (i.e. Jenkins).
It was recently updated to OpenJDK 8 Update 252 (we are using Amazon Corretto).

The problem can also be reproduced with the maven basic sonar example project,
which uses plugin version 3.6.0.1398 by default. I experimented a bit and could verify that it only happens with OpenJDK 8 Update 252, older versions work, as well as Java 11.
Unfortunately, we cannot switch to Java 11, because the project is bound to Java 8.

Then I analysed the network traffic between the Maven plugin and the SonarQube server, especially the TLS handshake. It turned out that with the updated Java the plugin offers to use HTTP/2, and the server agrees to it. But then the connection is terminated by the server.
Running an older Java version the plugin does not offer HTTP/2, actually the ALPN extension is completely missing in the Client Hello then. So if it was possible to disable HTTP/2 somehow it might solve the problem, but I have no idea how to do that.

Of course we can revert to and pin an older Java version, but then we will not get security fixes which is also not desirable.
I would be grateful for any further/better ideas how to solve this issue.

Thanks,
Hans-Peter

1 Like

Hi,
I failed to reproduce the problem with openjdk-8u252-b09-jre on Windows 10 connecting to SonarQube 8.4 w/https. Analyzing traffic, I see the extension ALPN in the client hello but it offers http/1.1.

I also see that running curl -I --http2 <server url> ends up using HTTP2 with several random servers but not with that instance of SonarQube over https. Here I see that curl offers http2 and http1.1 and I’m guessing this SQ instance only supports HTTP1.1 and it correctly falls back to it.

To be honest even if I could reproduce, I wouldn’t really know how to proceed from here.
To answer your question, I don’t know how to disable HTTP/2 in Java without changing the code.

Hi,

we had the exact same problem working with a gradle project build byJenkins. Also using Corretto 8u252 here, so this could be specific to this JDK type. After we switched back to an older version (242 in this case, as it was the previously used version) everything worked fine again.

SonarQube Version 8.2 (build 32929)
Jenkins ver. 2.204.2
Gradle(wrapper) 5.6.4
Gradle Sonarqube Plugin: 2.8

Regards
Marc

Hi,

one thing I didn’t know when I wrote my report was that there is a proxy in front of the SonarQube server here in our company (it was set up by a different department). The colleagues are using traefik v2.0 - from the documentation I can see that this has HTTP2 turned on, and hard-coded, so it can’t be disabled. To me it seems that this proxy accepts HTTP2 but the SonarQube server is not able to deal with it and so the connection is aborted (this is just a guess).

Regards,
Hans-Peter

Hi Hans,
I do confirm that this is coming from Traefik.
Your Post and this one led me to understand the issue.
I ended up running curls with http1.1 and comparing the responses then found this github issue
To fix this we had to upgrade Traefik and specify alpnProtocols in the dynamic config of traefik

1 Like