Svnkit-1.10.1 Jenkins plugin . Error when executing blame for file **/src/com/**/**/**/Filename.java - Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: Connection reset

SVNKit
#1

error.txt (6.6 KB)

Hi Team,

We are migrating from [Jenkins 2.235.5] and migrated one of the maven sonar scanner to the new Jenkins. But as part of the sonar analysis build fails executing blame for a file with svn: E175002: Connection reset .

This happens only for one file (32k lines of code with 10 year history ). This was working with fine with
Jenkins plugin version svnkit-1.8.6.jar but failing in svnkit-1.10.1.jar

Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: Connection reset
svn: E175002: REPORT request failed on '/svn//!svn/bc/151168/branches/<Finename>'
    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.DAVConnection.doReport (DAVConnection.java:353)
    at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getFileRevisionsImpl (DAVRepository.java:936)
    at org.tmatesoft.svn.core.io.SVNRepository.getFileRevisions (SVNRepository.java:763)
    at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteAnnotate.run (SvnRemoteAnnotate.java:109)
    at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteAnnotate.run (SvnRemoteAnnotate.java:30)
    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 org.tmatesoft.svn.core.wc.SVNLogClient.doAnnotate (SVNLogClient.java:295)
    at org.sonar.plugins.scm.svn.SvnBlameCommand.blame (SvnBlameCommand.java:83)
    at org.sonar.plugins.scm.svn.SvnBlameCommand.blame (SvnBlameCommand.java:58)
    at org.sonar.scanner.scm.ScmPublisher.publish (ScmPublisher.java:84)
    at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart (ProjectScanContainer.java:358)
    at org.sonar.core.platform.ComponentContainer.startComponents (ComponentContainer.java:137)
    at org.sonar.core.platform.ComponentContainer.execute (ComponentContainer.java:123)
    at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart (GlobalContainer.java:144)
    at org.sonar.core.platform.ComponentContainer.startComponents (ComponentContainer.java:137)
    at org.sonar.core.platform.ComponentContainer.execute (ComponentContainer.java:123)
    at org.sonar.batch.bootstrapper.Batch.doExecute (Batch.java:72)
    at org.sonar.batch.bootstrapper.Batch.execute (Batch.java:66)
    at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute (BatchIsolatedLauncher.java:46)

Please let me know if additional information is required

Regards
K

#2

Response from Sonar Source community requesting a review from SVNKIT team

#3

Hello,
from the first glance it looks like network problem, indeed. Sometimes SVN servers are set up in a way that they cut connection if it’s too slow or bytes sent limit is exceeded.

I believe we didn’t change anything major in HTTP-related code of SVNKit between 1.8.6 and 1.10.1. Do you have a possibility to conduct experiments?

There’re 2 approaches. If you’re familiar with Java, I would ask you to try minimal code that runs SVNRepository#getFileRevisions on your file (better separately but it could be a part of SvnRemoteAnnotate operation). It’s easier to do that inside local copy of SVNKit sources. Then if the problem is reproducible, use dichotomy (i.e. switch between SVNKit revisions in the sources directly) to find the SVNKit revision in which everything was broken.

The second approach is trickier: build SVNKit from sources, again using dichotomy principle, and substitute the JAR file with those intermediate builds. Again, this will help us find the SVNKit revision where everything was broken.

Thus we’ll be able to fix that offending revision.