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
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.
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)?
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.
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
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!
mbecker was there anything you did to resolve this? I’m getting this exact same issue.
builds being scanned by azure devops pipelines
java.net.SocketTimeoutException: Read timed out when hitting new_code_periods
nothing showing up in an access logs for that request at the timestamp of the reported failure
very sporadic. All other requests are fine, and 99% of the time new_code_periods works without issue. Usually the pipeline works on the next attempt immediately after the fail.