Subversion post commit hook notifyCommit response time far slower in Subversion plugin 1.45 vs 1.44 - causes svn checkouts to 'hang'

[Matt Seashore]

Please let me know if there's a better place to post this, after the Googling I've done it appears to be the right place.

I have a Subversion repository which contains quite a large number of externals (about 20, maybe more).  I then have a Subversion post-commit hook to trigger the jenkins build as per the wiki article here: https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin

I've noticed that in 1.44 of the Subversion Jenkins plugin, the wget notification POST to http://server/subversion/<reposi id>/notifyCommit?rev=$REV would return in easily under a second (wget just says 0 seconds).  However, in Subversion 1.45 it takes around 20 seconds for that wget call to return.  This wouldn't be so bad, except that the in the wiki article above it uses a 2 second timeout and no limit of retries (default of 20). This basically caused every SVN commit to take ~2 minutes (appears to hang if your expecting 2 seconds) while wget continually retries and the servers churn.

I've validated the issue is in the Subversion plugin as I've run into the issue on Jenkins 1.480.2 and 1.512 with the same result (1.44 is fast, 1.45 is slow)

My guess is that this slowness is related to: "Fixed: support for svn:externals (issue #16217 and issue #13790)" in 1.45.  This is just because I see a lot of messages around verifying credentials to the external links in the logs - not 100% sure.  I've figured out that I can work around the slow notifyCommit response time by setting a longer timeout (30 seconds) on the wget call, but it seems to me that the notifyCommit call should return before checking the externals (or whatever it's doing).  

So, my question is: is this a known issue with the Subversion plugin that it takes so long for notifyCommit to return with externals (I couldn't find an existing bug)?  Or is it OK and perhaps the wiki article should just have the default timeout/retried tweaked?  I think something needs to be done to address the issue as it was difficult to figure out that a Jenkins (subversion) update causes Subversion commits to take 2 minutes.

Please let me know if you need additional information around reproducing the issue or anything I can do to help.

Thanks,

Matt

[Jesse Glick]

On 04/29/2013 08:19 PM, Matt Seashore wrote:
> is this a known issue

If you have to ask, the answer is probably “no”. File it with whatever details to reproduce you can muster.

[Matt Seashore]

Fair enough.  I've filed a bug here: https://issues.jenkins-ci.org/browse/JENKINS-17808

[Kenny Ayers]

Are you looking for a temporary workaround?

Make the trigger asynchronous. There are a number of ways to do this, but since I prefer python I would add a line in your post-commit hook to call a python script which spins off another process to trigger the Jenkins update.

http://stackoverflow.com/questions/1718899/run-a-process-and-quit-without-waiting-for-it

You'll want to log the result somewhere since you won't get the return value from the async call in the post-commit script itself.

-Kenny

[Matt Seashore]

Thanks for the workaround.  I had just reverted to 1.44, but running asynchronously and logging the result would still keep the commits fast and give access to the return values which would be nice to have.  (Of course - I still think the issue should either be fixed or the wiki documentation updated so that future users of the SVN post-commit hook wouldn't run into this issue) 

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/nFGCnv_xyv4/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.