-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Verified Bug with Jenkins 1.480.2 on RHEL 4 running under Tomcat 5 (notify commit slow with SVN 1.45, fast with 1.44)
Also verified bug with Jenkins 1.512 on CentOS 5.7 running under Winstone (notify commit slow with SVN 1.45, fast with SVN plugin 1.44)
On each server, we have subversion (1.7) repository with many external links (>20) is set up to notify jenkins with the post-commit hook recommended on the Jenkins Subversion Wiki.Verified Bug with Jenkins 1.480.2 on RHEL 4 running under Tomcat 5 (notify commit slow with SVN 1.45, fast with 1.44) Also verified bug with Jenkins 1.512 on CentOS 5.7 running under Winstone (notify commit slow with SVN 1.45, fast with SVN plugin 1.44) On each server, we have subversion (1.7) repository with many external links (>20) is set up to notify jenkins with the post-commit hook recommended on the Jenkins Subversion Wiki.
With version 1.44 the notifyCommit wget request returns in well under a second (almost instantly). With Jenkins Subversion plugin 1.45 the notifyCommit wget returns in around 20 seconds. This basically means that even if we configure wget to have a 30 second timeout (and not retry) all SVN commits take ~20 seconds at a minimum!
This slow response time is made worse by having this being called by a post-commit hook in SVN and the prescribed wget call doesn't provide a 'tries' argument to limit retries. This causes wget to retry 20 times. The symptom is that I updated Jenkins and SVN commits suddenly take minutes of time (due to the interaction between wget retrying and the notifyCommit call taking 20 seconds).
I suspect this slowness has to do with svn:externals being resolved as that was added in 1.45 (Fixed: support for svn:externals (issue #16217 and issue #13790) and we have a lot of externals. If this is the case I would think that notifyCommit could return a response before resolving svn:externals.
I posted this question on the Google Group as well: https://groups.google.com/forum/?fromgroups=#!searchin/jenkinsci-dev/subversion%7Csort:date/jenkinsci-dev/nFGCnv_xyv4/a5IGqI1Hox0J
I can also provide more information if needed, just let me know what I can do or what would be helpful.
Steps to reproduce:
-Have an SVN repository with quite a few svn:externals (I haven't created a repository from scratch to test - I just know we have quite a few externals and have seen in the log them being resolved on when notifyCommit is called)
-Set up a post commit hook as per https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin to notify jenkins on commit.
-Perform a SVN commit and notice it takes a long time (2 minutes) to commit.
-Check the access log and you can see wget retrying about 20 times. If you run wget manually against notifyCommit and it will take about 20 seconds - far longer than the 2 second limit.
- duplicates
-
JENKINS-17616 Performance issue with Subversion plugin - trigger build on SVN commit takes too long
-
- Reopened
-
This bug is reproducible in the Jenkins version 1.633, with Subversion Plug-in 2.5.3 (pinned).
The error in the post-commit is:
Connecting to myjenkins:8080... connected.
HTTP request sent, awaiting response... Read error (Connection timed out) in headers.
I used the next timeout values: 2, 8, 16, 32, 64, 128, 256, 1024
In all cases the error is the same.
Does anybody knows a fix or workaround for this?