It takes very long time for a Surround SCM repository to be updated in the server cache

Continua CI Discussion
1

Version 1.8.1.121. After I check in files in Surround SCM it might take more than 10 minutes before the server cache in CI is updated. The polling frequency is set to Normal 60 sec.
This seems to increase more and more as times goes.

Regards
Sindre Barstad

2

Hi Sindre,

Can you provide more details so we can reproduce or diagnose this issue? What size is your repository? Are you seeing the delay before the changeset appears in the configuration Changes view, or when initialising the workspace when running a build - if so maybe you can show us the timeline and build log.

For a quicker diagnosis, enable debug logging. After restarting the Continua CI server service, commit a new change to the repository and start a build or wait for a build to be triggered. Once the build has finished, send the log file to support@finalbuilder.com and we’ll look for the cause of the bottleneck. We recommend installing the latest version of Continua CI first so that the logging matches the latest code.

Also let us know what version of Surround SCM server and client you are running.


3

Thanks. I’ll start with upgrading both CI and Surround, and then eventually turn on debug logging. The repository, as seen disk on the CI server, is 800 MB and 22000 files. The repository has 890 changesets.
The delay is before I can see the changeset appears. After commiting in Surround it will take at least 10 min. before I see the “updating cache” in the repository view and the changeset appears. In the mean time several “checks” has happened.

4

I’m pretty sure I’ve found the problem. There was a rather big time drift between the CI- and Surround Server, and from the debug log I found that you use a time span to watch for updates.

5

Hi Sindre,

Yes, the time difference would cause this problem. If you synchronise the times on the two servers then this should fix the issue for now. We shouldn’t however be relying on the times being the same, so I have now updated the code so the time span starts from the latest date-time of previous changesets (received from the Surround server). This will be in the next version.