nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

subversion plugin timing out on large commit in initial sync

Steve Banik

When I set up the Jira Subversion plugin, it times out on a large commit, part way through the initial sync. Is there something I can tune to increase the timeout period, or to get it to skip the commits prior to a certain revision?

The error is:

2014-03-14 12:20:30,210 QuartzScheduler_Worker-0 ERROR ServiceRunner com.atlassian.jira.plugin.ext.subversion.revisions.scheduling.UpdateIndexMonitorImpl:job [plugin.ext.subversion.SubversionManagerImpl] Error retrieving changes from the repository.

org.tmatesoft.svn.core.SVNException: svn: E175002: timed out waiting for server

svn: E175002: REPORT request failed on '/repos/repo/!svn/bc/63059'

It seems to be timing out on 45942 / 63060

ALM and default versions of the plugin both fail in the same way.

Accepted answers

All comments

Contact Kintosoft

When I set up the Jira Subversion plugin, it times out on a large commit, part way through the initial sync. ...

ALM and default versions of the plugin both fail in the same way.

What is a large commit?

It should not affect to the Atlassian's plugin as it only fecthes some few metadata for each commit (author, date, message).

ALM might be affected... if a large commit means a lot of changes paths, as ALM also fetches all the add/modified/deleted files and directories (therefore if the amount of changed paths is large it might affect to the ALM indexing performance).

If large commits means large file sizes (like a video, etc) then neither the Atlassian's plugin nor ALM should be affected as they do not read file contents.

As mentioned, if the Atlassian's plugin stops dues a time out, then the problem might not be related to commit sizes. Maybe the problem is in the message which has to be parsed in order to retrieve the embedded issue keys. If you see 45942 / 63060 from ALM then the problem is in the 45942+1=45943 revision.

Might you inspect that revision? Do you see something strange? How may changed paths does it have? How long is the commit message?

Timeouts might also be related to a slow connections? Is your JIRA instance accessing to Subversion over a WAN or a LAN?

Steve Banik

It does seem to be a case that it's the commit after the one reported that's the large one, in this case 700MB. It's connecting over a 1GB link to a local system, so network bandwidth and latency shouldn't be the issue.

Norman Abramovitz

If you restart the subversion alm indexing, does it move forward? Where you defined the repository, you need to activate it again to get indexing going again. Also make sure Jira's task scheduler is not paused.

Steve Banik

Seems fixed now, after I raised -Xmx and set:

JVM_SUPPORT_RECOMMENDED_ARGS="-Dcom.atlassian.jira.plugin.ext.subversion.svnreadtimeout=6000000"

Contact Kintosoft

How does this parameter affect to ALM? It is initally ignored (ALM relies on the Polarion Subversion connection management by default which hardcodes timeout to 3 minutes) so it would fail. Then, you could click on the Activate link which would rely on the Atlassian connection management which takes the timeout from this JVM system parameter (default is 2 minutes) and then it should work too.

Anyway, I'm going to unify the ALM connection managenment into a single point and support time out configuration from the GUI.

Thanks for this useful info!

Contact Kintosoft

FYI, the just released 5.8.3 version of ALM supports timeout configuration from the GUI without configuring and re-starting JIRA