Read timed out on /batch/project (SonarQube 4.5)

Question

I am struggling with the following problem.

Log of the executed when sonar-runner in Jenkins.

SonarQube Runner 2.4
Java 1.7.0_67 Oracle Corporation (64-bit)
Windows 7 6.1 amd64
SONAR_RUNNER_OPTS=-Xms256m -Xmx512m
INFO: Runner configuration file: D:\CI_BUILD\sonar-runner-2.4\conf\sonar-runner.properties
INFO: Project configuration file: NONE
INFO: Default locale: "ko_KR", source code encoding: "UTF-8"
INFO: Work directory: D:\CI_BUILD\jenkins_home\jobs\CAFE-CLIENT\workspace\.sonar
INFO: SonarQube Server 4.5
05:17:52.119 INFO  - Load global referentials...
05:17:53.382 INFO  - Load global referentials done: 1263 ms
05:17:53.414 INFO  - User cache: C:\Users\pcms_build\.sonar\cache
05:17:53.445 INFO  - Install plugins
05:17:54.225 INFO  - Install JDBC driver
05:17:54.303 INFO  - Create JDBC datasource for jdbc:jtds:sqlserver://10.240.232.145/sonardb;SelectMethod=Cursor
05:17:56.222 INFO  - Initializing Hibernate
05:17:59.217 INFO  - Load project referentials...
05:18:19.232 INFO  - Load project referentials done: 20015 ms
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
Total time: 34.757s
Final Memory: 21M/291M
INFO: ------------------------------------------------------------------------
ERROR: Error during Sonar runner execution
ERROR: Unable to execute Sonar
ERROR: Caused by: Unable to request: /batch/project?key=CAFE-CLIENT&preview=false
ERROR: Caused by: Read timed out
ERROR: 
ERROR: To see the full stack trace of the errors, re-run SonarQube Runner with the -e switch.
ERROR: Re-run SonarQube Runner using the -X switch to enable full debug logging.
Build step 'Invoke Standalone Sonar Analysis' marked build as failure

05:18:19.232 INFO - Load project referentials done: 20015 ms

When "Load project referentials done" value is larger than 20,000 ms,

Always "Read timed out" occurs.

Vicariate

Which "value" is "larger than 20,000 ms"? Can you retrieve the same URL by hand? – Dolomite

05:18:19.232 INFO - Load project referentials done: 20015 ms. Error Occur condition : Load project referentials > 20,000 ms – Vicariate

There is SONAR-5849 which supposedly addressed and fixed this issue in both 4.5.x and 5.x - but the latest message in the original mail thread as well as my personal experience tell a different story. – Disobey

...and there is SONAR-6063 and a proposed snapshot build to fix the problem, but at least in my case (Sonar 5.0 w/PostgreSQL 9.3), this also didn't help. – Disobey

If it doesn't fix your issue could you please provide details on user mailing list: your DB version and full server side logs so that Julien L can investigate. Thanks – Vlf

I'll try to do that - but I can already tell you: It's the same 20sec timeout issue. Sonar causes a lot of load. When other stuff on the same machine happens, the Sonar job may thus fail. Please make this timeout configurable. We've mitigated by running the Sonar job on it's own machine. But even now we're getting the error, albeit, much much rarer than before (~1 timeout in 10 runs vs ~8 in 10). – Disobey

Answer 1

Loading of project referentials is not expected to take more than a few seconds. It is very likely you have a performance issue on your SQ server (or with your DB). Here are some criteria that may increase duration of this web service:

• you have installed a lot of language plugins or you have enabled a lot of rules in quality profiles
• your project is a multi-module project with a lot of modules

Compare for example with: http://nemo.sonarqube.org/batch/project?key=org.codehaus.sonar%3Asonar&preview=true

that returns more than 1000 rules and 33 modules. It takes less than 2 seconds to return data.

EDIT: it seems there was some SQL issues depending on your DB vendor. See http://jira.codehaus.org/browse/SONAR-5849 and http://jira.codehaus.org/browse/SONAR-6063. Should be fixed in upcoming 4.5.3

Vlf

I am also running into this issue on 4.5.2. In SONAR-5849 it is mentioned that a change was made to "Allow to configure HttpDownloader TIMEOUT instead of having a hard coded value of 20 seconds". How can we take advantage of this to work around this problem? – Sungsungari

@ioscode: apparently, you cannot, because it was decided to not set this timeout tweakable because we should be able to do what need to be done in less that 30 seconds. – Disobey