Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-17431

500 Internal Server Error on attempt to run a build

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Critical
    • Resolution: Unresolved
    • Component/s: subversion-plugin
    • Labels:
      None
    • Environment:
      linux redhat 2.6.18-238.el5
    • Similar Issues:

      Description

      jenkins throws :
      ERROR: Failed to update https://XXXXXXX
      org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT of '/svn/playspan/!svn/vcc/default': 500 Internal Server Error

      on attempt to run build.
      on svn server side in the error log:
      " Could not access revision times. 500, #0"

      I think what happened was:
      when build is requested, svnkit is trying to run svn log on the svn server by runnint it between two time stamps - previous build and current time. sometimes either dates were not recorded on svn server or the current dated obtained on the jenkins server is running ahead of svn server and, I think, this causes the problem.
      my suggestion:
      do not use timestamp at all
      instead run log (or svn diff) between two revision numbers, which are always present on svn server.
      2. I think running svn log on remote svn server is not very efficient.
      I think, would be better:
      1. when build is requested, capture current revision on the working space.
      2. run svn update
      3. capture the revision
      4. run log or diff locally between two revisions.

      this way, jenkins will communicate to svn server just once instead of multiple times.

        Attachments

          Issue Links

            Activity

            Hide
            saretter Sascha Retter added a comment -

            At the moment our workaround is to append @HEAD to the subversion-urls

            Show
            saretter Sascha Retter added a comment - At the moment our workaround is to append @HEAD to the subversion-urls
            Hide
            saretter Sascha Retter added a comment -

            After discussing the problem on the subversion-users mailinglist (http://mail-archives.apache.org/mod_mbox/subversion-users/201509.mbox/browser) in my opinion jenkins' subversion plugin should not rely on timestamps at all.

            Show
            saretter Sascha Retter added a comment - After discussing the problem on the subversion-users mailinglist ( http://mail-archives.apache.org/mod_mbox/subversion-users/201509.mbox/browser ) in my opinion jenkins' subversion plugin should not rely on timestamps at all.
            Hide
            saretter Sascha Retter added a comment -

            Most probably.

            Show
            saretter Sascha Retter added a comment - Most probably.
            Hide
            recena Manuel Recena Soto added a comment -

            Sascha Retter, I would like to help here. Do you think the problem is related with Subversion Plugin?

            Show
            recena Manuel Recena Soto added a comment - Sascha Retter , I would like to help here. Do you think the problem is related with Subversion Plugin?
            Hide
            saretter Sascha Retter added a comment -

            Manuel Recena Soto the problem itself in my point of view is originally a huge problem in subversion and how it handles revisions and history of commits. But after my conversation with Eric Johnson on the subversion mailinglist (http://mail-archives.apache.org/mod_mbox/subversion-users/201509.mbox/browser) I think there is no way to fix that on subversion side which led me to the conclusion that you cannot rely on any subversion-operation that somehow uses timestamps.

            So I think it would be best if SVN-Plugin could be implemented not using timestamps anymore. But in my opinion that would require a lot of changes and I don’t have enough knowledge about the implementation of the SVN-Plugin to say whether it is even possible.

            Show
            saretter Sascha Retter added a comment - Manuel Recena Soto the problem itself in my point of view is originally a huge problem in subversion and how it handles revisions and history of commits. But after my conversation with Eric Johnson on the subversion mailinglist ( http://mail-archives.apache.org/mod_mbox/subversion-users/201509.mbox/browser ) I think there is no way to fix that on subversion side which led me to the conclusion that you cannot rely on any subversion-operation that somehow uses timestamps. So I think it would be best if SVN-Plugin could be implemented not using timestamps anymore. But in my opinion that would require a lot of changes and I don’t have enough knowledge about the implementation of the SVN-Plugin to say whether it is even possible.

              People

              • Assignee:
                recena Manuel Recena Soto
                Reporter:
                smasleni Slava Maslenitsyn
              • Votes:
                11 Vote for this issue
                Watchers:
                15 Start watching this issue

                Dates

                • Created:
                  Updated: