Risk-prone wiki recommendations for SVN post-commit hook?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Risk-prone wiki recommendations for SVN post-commit hook?

David Pärsson
Hi,

In short: Should the --timeout=2 really be recommended in the post-commit hook on the SVN wiki page, without a lower maximum number of retries? It may cause Jenkins to become unresponsive.

Here's why: In our SVN repo we have a lot of different modules with several branches. Each module is configured as a separate repo in our Jenkins builds, but since they all reside in the same repo, every commit causes Jenkins to check hundreds of different URLs in the same repo. This can obviously take more than 2 seconds. If it does, the wget call tries again, causing Jenkins to check for changes in any of the modules in the SVN repo again.

Since the notifyCommit calls as synchronized (in svnkit, at least getUUID()), this probably causes the following wget retry attempt to timeout as well. This can cause up to 20 notifications from the single wget, blocking 20 Jenkins threads. It does not take that many commits before Jenkins runs out of threads and becomes unresponsive.

Suggestions: Either increase the recommended timeout, or include the --tries=1 flag in the recommended post-commit hook. The latter may cause wget to be more prone to exit with a non-zero exit code. Finally one could also suggest to remove the timeout, ignore the exit status of wget and let it run asynchronously by adding 2>&1 & at the.

Finally: Should i update the wiki? Which of the suggestions do you prefer?
Reply | Threaded
Open this post in threaded view
|

Re: Risk-prone wiki recommendations for SVN post-commit hook?

Dean Yu-2
Hi David,
  Thanks for pointing this out. I think it's worth creating a "Considerations" sub-topic of the post-commit hook on the page that has the details you've described before. Please go ahead and update the wiki.

  -- Dean

From: David Pärsson <[hidden email]>
Reply-To: "[hidden email]" <[hidden email]>
Date: Wednesday, December 19, 2012 5:19 AM
To: "[hidden email]" <[hidden email]>
Subject: Risk-prone wiki recommendations for SVN post-commit hook?

Hi,

In short: Should the --timeout=2 really be recommended in the post-commit hook on the <a href="https://wiki.jenkins-ci.org/display/JENKINS/Subversion&#43;Plugin#SubversionPlugin-Postcommithook"> SVN wiki page, without a lower maximum number of retries? It may cause Jenkins to become unresponsive.

Here's why: In our SVN repo we have a lot of different modules with several branches. Each module is configured as a separate repo in our Jenkins builds, but since they all reside in the same repo, every commit causes Jenkins to check hundreds of different URLs in the same repo. This can obviously take more than 2 seconds. If it does, the wget call tries again, causing Jenkins to check for changes in any of the modules in the SVN repo again.

Since the notifyCommit calls as synchronized (in svnkit, at least getUUID()), this probably causes the following wget retry attempt to timeout as well. This can cause up to 20 notifications from the single wget, blocking 20 Jenkins threads. It does not take that many commits before Jenkins runs out of threads and becomes unresponsive.

Suggestions: Either increase the recommended timeout, or include the --tries=1 flag in the recommended post-commit hook. The latter may cause wget to be more prone to exit with a non-zero exit code. Finally one could also suggest to remove the timeout, ignore the exit status of wget and let it run asynchronously by adding 2>&1 & at the.

Finally: Should i update the wiki? Which of the suggestions do you prefer?