Random SonarScaner failures

Periodically we are seeing sonar scanner fail with the following error:

INFO: Load global settings
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
INFO: Total time: 9.690s
INFO: Final Memory: 6M/15M
INFO: ------------------------------------------------------------------------
ERROR: Error during SonarScanner execution
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'org.sonarsource.scanner.api.internal.IsolatedClassloader@49e53c76-org.sonar.scanner.bootstrap.ScannerPluginRepository': Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'org.sonarsource.scanner.api.internal.IsolatedClassloader@49e53c76-org.sonar.scanner.bootstrap.ScannerPluginInstaller': Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'org.sonarsource.scanner.api.internal.IsolatedClassloader@49e53c76-org.sonar.scanner.bootstrap.PluginFiles': Unsatisfied dependency expressed through constructor parameter 1; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'GlobalConfiguration' defined in org.sonar.scanner.bootstrap.GlobalConfigurationProvider: Unsatisfied dependency expressed through method 'provide' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'GlobalServerSettings' defined in org.sonar.scanner.bootstrap.GlobalServerSettingsProvider: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.sonar.scanner.bootstrap.GlobalServerSettings]: Factory method 'provide' threw exception; nested exception is java.lang.IllegalStateException: Fail to request url: https://<REDACTED>/api/settings/values.protobuf
	at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:800)
	at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:229)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1372)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1222)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:582)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:542)
	at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:335)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:333)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:208)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:955)
	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:920)
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:583)
	at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:187)
	at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
	at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:71)
	at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:65)
	at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
	at jdk.proxy1/jdk.proxy1.$Proxy0.execute(Unknown Source)
	at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:189)
	at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:138)
	at org.sonarsource.scanner.cli.Main.execute(Main.java:126)
	at org.sonarsource.scanner.cli.Main.execute(Main.java:81)
	at org.sonarsource.scanner.cli.Main.main(Main.java:62)
Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 

(This is truncated as there is more to the stack trace, but I am not sure how helpful it would be.)

To mitigate this, we have created a retry loop which always seems to succeed on the next scanner attempt, but looking at the server side logs I don’t see anything out of the ordinary which suggests why this could be happening. Since we can reliably get the retry to pass, it’s not a huge issue… but it seems like the scanner itself should retry when this happens rather than throw a stack trace and bail out.

  • SonarQube 10.1.0.73491
  • Deployed via Helm Chart
  • SonarScanner 5.0.1.3006 (via sonarsource docker image)

Hi,

Here’s the root problem:

My guess is that you have something “helpful” on the network that’s interfering.

 
Ann

Is there any way to have the scanner/client retry failed connections?

Hi,

Well, there’s no current switch or flag to enable that behavior because we haven’t seen the need to build that in.

Do you have a use case where network availability is legitimately intermittent.?

 
Ann