We just migrated from SonarQube 6.x to SonarQube 8.x.
SonarLint 4.16.0.31683 was the most recent version of the plugin I could use with SonarQube 6.x and it worked fine.
Today I updated to SonarLint 6.3.1.40498 right after we migrated to SonarQube 8.x, and IntelliJ became unresponsive for several minutes during startup:
"AWT-EventQueue-0" prio=0 tid=0x0 nid=0x0 waiting on condition
java.lang.Thread.State: WAITING
on java.util.concurrent.CompletableFuture$Signaller@3b4bb82
at java.base@11.0.13/jdk.internal.misc.Unsafe.park(Native Method)
at java.base@11.0.13/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at java.base@11.0.13/java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1796)
at java.base@11.0.13/java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3128)
at java.base@11.0.13/java.util.concurrent.CompletableFuture.waitingGet(CompletableFuture.java:1823)
at java.base@11.0.13/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1998)
at org.sonarlint.intellij.http.ApacheHttpClient.get(ApacheHttpClient.kt:59)
at org.sonarsource.sonarlint.core.serverapi.ServerApiHelper.rawGet(ServerApiHelper.java:94)
at org.sonarsource.sonarlint.core.notifications.NotificationChecker.isSupported(NotificationChecker.java:76)
at org.sonarsource.sonarlint.core.notifications.ServerNotificationsRegistry.isSupported(ServerNotificationsRegistry.java:70)
at org.sonarlint.intellij.core.ServerNotificationsService.isSupported(ServerNotificationsService.java:50)
at org.sonarlint.intellij.notifications.ProjectServerNotificationsSubscriber.register$lambda-4(ProjectServerNotificationsSubscriber.kt:105)
at org.sonarlint.intellij.notifications.ProjectServerNotificationsSubscriber$$Lambda$6313/0x0000000802868840.accept(Unknown Source)
at java.base@11.0.13/java.util.Optional.ifPresent(Optional.java:183)
at org.sonarlint.intellij.notifications.ProjectServerNotificationsSubscriber.register(ProjectServerNotificationsSubscriber.kt:102)
at org.sonarlint.intellij.notifications.ProjectServerNotificationsSubscriber.start(ProjectServerNotificationsSubscriber.kt:70)
at org.sonarlint.intellij.BootstrapStartupActivity.runActivity(BootstrapStartupActivity.java:44)
at com.intellij.ide.startup.impl.StartupManagerImpl.runStartupActivity(StartupManagerImpl.kt:312)
After a few minutes (a timeout I guess), the IDE becomes responsive, but actions like Loading taint vulnerabilities and Update bindings fail to connect to the server.
When I revert back to SonarLint 4.16.0.31683 I get no issue, and the plugin can reach SonarQube 8.x just fine.
Out SonarQube instance requires a client certificate, which is configured in idea.vmoptions like this:
Not sure if this is related to the problem, but it’s a rather unusual config so it might explain why nobody else is complaining about this kind if problem here.
First of all we are aware of UI freezing issues and already started fixing some on them. More fixes should land in the future.
At the moment those kind of freezes happen when SonarLint tries to reach the server and doesn’t get any response (e.g. when the server or network is down). Here it probably happens because the configuration for your client certificate is wrong. Your server/proxy might ignore the request when the client certificate can’t be found.
May I ask you why you use those values here ? What format is your key store (that contains the client certificate) ? If you used the JKS format, you can simply omit the javax.net.ssl.keyStoreType property and only provide the path to your keystore in javax.net.ssl.keyStore.
I fixed part of the problem by upgrading SonarLint to the latest version of httpclient5.
I tried to reproduce how SonarLint uses HttpAsyncClients, and got the same problem (no response).
By setting the response timeout to 5s instead of the default 10 minutes (!), my FutureCallback was called after those 5s, with the following error:
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: protocol_version
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:336)
at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293)
at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:185)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:681)
at java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:636)
at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:454)
at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:433)
at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:637)
at org.apache.hc.core5.reactor.ssl.SSLIOSession.doUnwrap(SSLIOSession.java:287)
at org.apache.hc.core5.reactor.ssl.SSLIOSession.decryptData(SSLIOSession.java:535)
at org.apache.hc.core5.reactor.ssl.SSLIOSession.access$400(SSLIOSession.java:72)
at org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:172)
at org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:133)
at org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
at org.apache.hc.core5.reactor.SingleCoreIOReactor.processEvents(SingleCoreIOReactor.java:179)
at org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:128)
at org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:85)
at org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
at java.base/java.lang.Thread.run(Thread.java:829)
After upgrading to httpclient5 5.1.2, the problem is gone.
Now my next problem is that the TLS strategy built in ApacheHttpClient.kt seems to completely ignore system properties like -Djavax.net.ssl.keyStoreType. Instead it relies on CertificateManager.getInstance().sslContext, which I suppose only manages server certificates configured in Preferences | Tools | Server Certificates. I.e. the SSLContext contains only a trust store and not a key store.
May I ask you why you use those values here ?
It’s a client certificate stored in macos’s Keychain.app, not in a JKS file.
Well, forget what I said, I wasn’t setting VM options properly in my debugged IDE. Everything works fine now.
I updated the httpclient/httpcore jars in ~/Library/Application Support/JetBrains/IntelliJIdea2021.3/plugins/sonarlint-intellij/lib to version 5.1.3 and now everything works as usual in my main IDE.
Do you think it could be possible to update these dependencies in the next version of SonarLint?
Thanks for investigating this on your side. I guess it wouldn’t hurt much to update the dependency on our side, I created the PR and I will do more testing today.
Please note that it won’t probably get released for some weeks as we are busy on some other topics at the moment.