SVN 签出有时在 Jenkins 中失败

Question

We have been experiencing a problem for a while now with SVN checkouts in Jenkins. It sometimes fails with the following error:

 org.tmatesoft.svn.core.SVNException: svn: E175002: Connection reset svn: E175002: REPORT request failed on '/Our-project/.svn/vcc/default' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager:java.112) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager:java.96) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection:java.765) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection:java.352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection:java.340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection:java.910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection:java.363) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository:java.1349) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository:java.847) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate:java.263) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate:java.115) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate:java.877) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout:java.26) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout:java.11) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner:java.20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner:java.21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory:java.1239) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation:java.294) at hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater:java.132) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater:java.168) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater:java.176) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater:java.133) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater:java.168) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM:java.1040) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM:java.1016) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM:java.989) at hudson.FilePath$FileCallableWrapper.call(FilePath:java.3052) at hudson.remoting.UserRequest.perform(UserRequest:java.212) at hudson.remoting.UserRequest.perform(UserRequest:java.54) at hudson.remoting.Request$2.run(Request:java.369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService:java.72) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1.lambda$newThread$0(Engine:java.93) at java.lang.Thread:run(Unknown Source) Caused by. java.net:SocketException: Connection reset

Recently it has started to happen a lot more and it happens when the combination of one specific repo is checked out by one specific Jenkins node. We have other nodes which are pretty much identical to this one where it practically never happens. We have other repos (both significantly larger and smaller) which are being checked out just as much as this one, but hardly ever causes this problem. This combination of repo and node seems to be very unfavourable.

It is worth noting that we are using a Jenkins plugin and doing the checkout via Groovy in the following way:

checkout(
    [$class: 'SubversionSCM',
    locations: 
    [
        [credentialsId: '6615cd79-bd58-42f8-1111-6fa9e5692f92',
         remote: <SVN URL>,
         local: 'our_dir']
    ],
    workspaceUpdater: [$class: 'UpdateWithCleanUpdater']])

When we instead checkout by running SVN command directly, we never run into this problem, meaning that the instability must reside in the plug-in. We do however need to keep using the plug-in for other reasons.

It also seems to happen more frequently when the node is stressed, ie when it is running multiple checkouts simultaneously on different executors.

Any input on how to resolve this would be appreciated.

We have unsuccessfully tried to use the -Dhudson.spool-svn flag discussed [here]. 1

Answer 1

@m1haus I think I got it. It is occurring because it's fetching too many files from svn and timing out. I just reduced the number of files and it worked