1

I've been using sonarqube for a long time. More specifically I was using version 4.2 during the last months without any problems. Yesterday I updated sonarqube to its last version, 4.5.2, but now I'm facing intermittent failures when I issue a "mvn sonar:sonar" during my build process. That is, sometimes the whole build works as expected, but most of the attempts fail with errors like this:

build   10-Jan-2015 16:50:57    [ERROR] Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.4:sonar (default-cli) on project project-parent: Unable to request: /batch/project?key=br.com.codersapiens:project-parent&preview=false: Read timed out -> [Help 1]

It seems that my CI server is not properly sized for the tools I use (basically, Bamboo and Sonarqube):

apps@ubuntu12:~# uptime 
 16:50:01 up 172 days, 19:22,  2 users,  load average: 2.55, 2.06, 1.56

This virtual machine has only one virtual processor:

apps@ubuntu12:~# cat /proc/cpuinfo | grep "model name"
model name  : Intel Core Processor (Haswell)

Regardless the high load for this modest VM, the build used to finish properly, with complete sonar analysis, when I was using qube's version 4.2.

Is this new version of sonarqube less tolerant to eventual delays caused by a busy host? Is there some way of setting this read timeout to bigger values?

Loreno Oliveira
  • 337
  • 1
  • 8
  • 19
  • 1
    As far as I can tell, there isn't (yet). Also, you're by far not the only one to experience this. Have a look at my comments ([1](http://stackoverflow.com/questions/26419286/about-read-timed-out-sonarqube-4-5/26420865#comment44711637_26419286), [2](http://stackoverflow.com/questions/26419286/about-read-timed-out-sonarqube-4-5/26420865#comment44714448_26419286)) - and the links mentioned in them - on this question: [About Read timed out (SonarQube 4.5)](http://stackoverflow.com/questions/26419286/about-read-timed-out-sonarqube-4-5) – zb226 Jan 28 '15 at 09:26
  • 1
    After some analysis I found that the VM was struggling with swapping. As a quick workaround I updated my VM to another one with twice the memory from the previous one. This solved my problem but at the price of twice the cost I had before upgrading. – Loreno Oliveira Jan 29 '15 at 15:54
  • Yes, throwing resources at the problem does mitigate it - we did the same. Good to hear you can consider it solved now :) I still think software shouldn't impose lower resource limits without a really good reason, though - and in this case, I can't see any. But of course I might be missing pieces of the big picture. – zb226 Jan 29 '15 at 16:11

0 Answers0