Sporadically timeout on GET for new_code_periods

Sonar-scanner frequently reports timeout failure on the GET call to new_code_periods

  • versions used: SonarQube server 8.9.2, SonarScanner 4.6.2.2472 running on Java 11.0.11 AdoptOpenJDK (64-bit), Linux 5.8.0-1043-azure amd64
  • error observed (’’’

java.lang.IllegalStateException: Fail to request url: https://serverfqdn/sonar/api/new_code_periods/show.protobuf?project=prjname&branch=branchname

Caused by: java.net.SocketTimeoutException: connect timed out
‘’’)

  • steps to reproduce:
  • call to new_code_periods from Azure DevOps pipeline fails very frequently with the Timeout error as seen above
  • sometimes it succeeds ("Load New Code definition (done) time=<various intervals, from 100 msecs to 3200 msecs>
  • potential workaround: no workaround found

What can be done on the client to avoid the timeout failure?
If no workarounds on the client - which setting should be adjusted on the server?
Thx in advance

any suggestions here?

Hi,

Welcome to the community!

I would start by looking at your access logs. Do the timed-out requests actually reach SonarQube? If so, we can look at what’s happening there. Otherwise, there is likely something on your network, e.g. a proxy, that’s blocking or slowing down the request. You should check with your network folks.

 
HTH,
Ann

Hi G Ann, thx for RE:
Actually we requested the service fellows to share the affected access.log. The communication to the server seems to be ok - all the previous calls to the service succeeded, but only this one - and not always, but most the times - gets abandoned with timeout exception.
From the client perspective there’s no proxy or gateways: we run the client in a container on an Azure VM (VM ScaleSet to be precise). The service staff informs there aren’t any filters or so in front of the service endpoint.
Is there any setting to increase or at least read the timeout setting on the client side (sonar-scanner)?

Thx in advance
Mike

Hi Mike,

What I’m asking is that you go back to an analysis with this error and correlate that request with a line in the access log. I would like to explicitly verify that SonarQube received that specific request. If the request is getting lost somewhere between build agent & SQ then it won’t show up in the access log.

 
Ann

Thx again, G Ann, quite my impression - if access.log doesn’t contain any related entries, we will start the investigations of the end to end network channel.
Not being a Java expert, I was just asking for any configuration oppties to extend the timeout on the client side (do you know any?).
Somehow, it seems to be related to the “Load New Code definition” call, so I suggest it hits in the situations, where the coverage data sent to the server plays a role.
Anyway, we follow your suggestion and start with the access.log on the server.
Thx again
Mike

Hi Mike,

Sorry, I forgot that part: sonar.ws.timeout (docs).

Mmm… nothing’s sent to the server until the full analysis report is submitted at the end.

 
HTH,
Ann

Oh! good to know, thx. So the assumption, the oversized coverage file may cause the timeout is wrong? We observed succeeded runs once the coverage file was replaced by an empty xml file at the last moment before analysis start… So the access.log should provide us with the info. Thx again!

Given the call you’re failing on, yes, I believe so. The error message (at least what’s posted) isn’t explicit, but that’s just a GET.

 
Ann