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

500 Internal Server Error on attempt to run a build

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • subversion-plugin
    • None
    • linux redhat 2.6.18-238.el5

      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.

          [JENKINS-17431] 500 Internal Server Error on attempt to run a build

          Slava Maslenitsyn created issue -

          hello,
          my I also suggest yet another approach.
          1. cd to checkout directory
          2. capture hd1 the amount of hard drive space taken
          3. run svn update .
          4. capture hd2 the amount of hard drive space taken
          if hd1 != hd2 - there are changes in this working space - run the build. I think it will be even more efficient then local svn command, so less time spent on the build + more reliable.

          regards,
          Slava

          Slava Maslenitsyn added a comment - hello, my I also suggest yet another approach. 1. cd to checkout directory 2. capture hd1 the amount of hard drive space taken 3. run svn update . 4. capture hd2 the amount of hard drive space taken if hd1 != hd2 - there are changes in this working space - run the build. I think it will be even more efficient then local svn command, so less time spent on the build + more reliable. regards, Slava

          kutzi added a comment -

          Why would a timestamp not be recorded on the svn server? IMO that's not possible: a revision has always also a timestamp.

          Can you give the full stacktrace of the error?

          kutzi added a comment - Why would a timestamp not be recorded on the svn server? IMO that's not possible: a revision has always also a timestamp. Can you give the full stacktrace of the error?
          kutzi made changes -
          Priority Original: Blocker [ 1 ] New: Major [ 3 ]

          thank you for responding. i see it has been changed to major from blocker... i think it should be blocker, as this problem prevents build to run... and our build engineer after we got this 500 response, ran build manually with mvn command... and build was fine. so, this tells me, that there is nothing wrong with the code, nor with subversion.
          and, please, let me make my point clearer. I saw the plugin code - it is very interesting and neat... however, I think in order to make a decision whether or not to run the build - you don't need to obtain the time and run svn command to see if there is any difference in the code between timestamps. 1. the difference can be found in easier way. svn -r <revision-number> is one of them.
          2. the timestamp itself... is never reliable thing, in my opinion. there so many things affecting it, so you simply cannot rely on it. name just a few, would be: the precision you are retriving timestamp and other computer is different. the time between machines is NEVER the same. even ntpd server is synchronizing it, however, it runs periodically, plus, if nptd finds significant difference, it won't adjust time fully, being afraid to break system dependant thing, so will do it gracefuly... while your program obtains time...
          i can list some other things affecting timestamp... if you want to...
          so, my main point is do not use timestamp to calculate difference. i think would be easier and faster to calculate size of checked out space before svn update and after.
          ...and I am not saying that svn response on it is completely valid... 500 error actually perhaps not the best answer... but this is just a matter of how developer typed in the text in response to the error. and according to what I see in subversion code, and how I understand it - subversion could not find such timestamp in its db, so... responded... why it could not find it? could be because this time doesn't exist yet (like i said... time on the machine sending the request is running a little bit ahead of svn server), or it is being malformed somehow, or it is something else... it is not easy to process timestamps...

          anyway, please see below the errors:
          ERROR: Failed to update https://svn.xxx.com:xxx/svn/XXXXXXXXXXXXXXX
          org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT of '/svn/xxxxx/!XXX/default': 500 Internal Server Error (https://xxxx.com:xxx)
          at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
          at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
          at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getDatedRevision(DAVRepository.java:207)
          at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:475)
          at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:464)
          at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:486)
          at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364)
          at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274)
          at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
          at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
          at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
          at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
          at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291)
          at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
          at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
          at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
          at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:143)
          at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:153)
          at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:903)
          at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:884)
          at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:867)
          at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2348)
          at hudson.remoting.UserRequest.perform(UserRequest.java:118)
          at hudson.remoting.UserRequest.perform(UserRequest.java:48)
          at hudson.remoting.Request$2.run(Request.java:326)
          at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
          at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
          at java.util.concurrent.FutureTask.run(FutureTask.java:138)
          at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
          at java.lang.Thread.run(Thread.java:662)
          Caused by: svn: E175002: REPORT of '/svn/xxxxxx/default': 500 Internal Server Error (https://xxxxx.com:xxx)
          at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
          at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189)
          at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:452)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.readError(HTTPRequest.java:288)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:213)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:460)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:335)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:325)
          at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getDatedRevision(DAVRepository.java:200)
          ... 28 more
          ERROR: Subversion update failed
          hudson.util.IOException2: remote file operation failed: /svn/xxxxxxxxx
          at hudson.remoting.Channel@6b1701fd:xxxxxxxx
          at hudson.FilePath.act(FilePath.java:861)
          at hudson.FilePath.act(FilePath.java:838)
          at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:843)
          at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:781)
          at hudson.model.AbstractProject.checkout(AbstractProject.java:1364)
          at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:670)
          at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
          at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:575)
          at hudson.model.Run.execute(Run.java:1575)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
          at hudson.model.ResourceController.execute(ResourceController.java:88)
          at hudson.model.Executor.run(Executor.java:237)
          Caused by: java.io.IOException
          at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:184)
          at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:153)
          at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:903)
          at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:884)
          at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:867)
          at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2348)
          at hudson.remoting.UserRequest.perform(UserRequest.java:118)
          at hudson.remoting.UserRequest.perform(UserRequest.java:48)
          at hudson.remoting.Request$2.run(Request.java:326)
          at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
          at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
          at java.util.concurrent.FutureTask.run(FutureTask.java:138)
          at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
          at java.lang.Thread.run(Thread.java:662)
          Caused by: hudson.scm.subversion.UpdaterException: failed to perform svn update
          ... 15 more
          Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT of '/xxxxxx/default': 500 Internal Server Error (https://xxxx.com:xxxxx)
          at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
          at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
          at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getDatedRevision(DAVRepository.java:207)
          at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:475)
          at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:464)
          at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:486)
          at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364)
          at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274)
          at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
          at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
          at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
          at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235)
          at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291)
          at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311)
          at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291)
          at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387)
          at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:143)
          ... 14 more
          Caused by: svn: E175002: REPORT of '/xxxx': 500 Internal Server Error (https://xxxx.com:xxx)
          at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
          at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189)
          at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:452)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.readError(HTTPRequest.java:288)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:213)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:460)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364)
          at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:335)
          at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:325)
          at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getDatedRevision(DAVRepository.java:200)
          ... 28 more

          Slava Maslenitsyn added a comment - thank you for responding. i see it has been changed to major from blocker... i think it should be blocker, as this problem prevents build to run... and our build engineer after we got this 500 response, ran build manually with mvn command... and build was fine. so, this tells me, that there is nothing wrong with the code, nor with subversion. and, please, let me make my point clearer. I saw the plugin code - it is very interesting and neat... however, I think in order to make a decision whether or not to run the build - you don't need to obtain the time and run svn command to see if there is any difference in the code between timestamps. 1. the difference can be found in easier way. svn -r <revision-number> is one of them. 2. the timestamp itself... is never reliable thing, in my opinion. there so many things affecting it, so you simply cannot rely on it. name just a few, would be: the precision you are retriving timestamp and other computer is different. the time between machines is NEVER the same. even ntpd server is synchronizing it, however, it runs periodically, plus, if nptd finds significant difference, it won't adjust time fully, being afraid to break system dependant thing, so will do it gracefuly... while your program obtains time... i can list some other things affecting timestamp... if you want to... so, my main point is do not use timestamp to calculate difference. i think would be easier and faster to calculate size of checked out space before svn update and after. ...and I am not saying that svn response on it is completely valid... 500 error actually perhaps not the best answer... but this is just a matter of how developer typed in the text in response to the error. and according to what I see in subversion code, and how I understand it - subversion could not find such timestamp in its db, so... responded... why it could not find it? could be because this time doesn't exist yet (like i said... time on the machine sending the request is running a little bit ahead of svn server), or it is being malformed somehow, or it is something else... it is not easy to process timestamps... anyway, please see below the errors: ERROR: Failed to update https://svn.xxx.com:xxx/svn/XXXXXXXXXXXXXXX org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT of '/svn/xxxxx/!XXX/default': 500 Internal Server Error ( https://xxxx.com:xxx ) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getDatedRevision(DAVRepository.java:207) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:475) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:464) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:486) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:143) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:153) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:903) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:884) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:867) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2348) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: svn: E175002: REPORT of '/svn/xxxxxx/default': 500 Internal Server Error ( https://xxxxx.com:xxx ) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:452) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.readError(HTTPRequest.java:288) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:213) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:460) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:335) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:325) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getDatedRevision(DAVRepository.java:200) ... 28 more ERROR: Subversion update failed hudson.util.IOException2: remote file operation failed: /svn/xxxxxxxxx at hudson.remoting.Channel@6b1701fd:xxxxxxxx at hudson.FilePath.act(FilePath.java:861) at hudson.FilePath.act(FilePath.java:838) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:843) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:781) at hudson.model.AbstractProject.checkout(AbstractProject.java:1364) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:670) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:575) at hudson.model.Run.execute(Run.java:1575) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:237) Caused by: java.io.IOException at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:184) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:153) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:903) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:884) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:867) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2348) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: hudson.scm.subversion.UpdaterException: failed to perform svn update ... 15 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT of '/xxxxxx/default': 500 Internal Server Error ( https://xxxx.com:xxxxx ) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getDatedRevision(DAVRepository.java:207) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:475) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:464) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:486) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:143) ... 14 more Caused by: svn: E175002: REPORT of '/xxxx': 500 Internal Server Error ( https://xxxx.com:xxx ) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:452) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.readError(HTTPRequest.java:288) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:213) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:460) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:335) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:325) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getDatedRevision(DAVRepository.java:200) ... 28 more

          just FYI:
          http://svnbook.red-bean.com/en/1.7/svn.tour.revs.specifiers.html

          Since the timestamp of a revision is stored as an unversioned, modifiable property of the revision (see the section called “Properties”), revision timestamps can be changed to represent complete falsifications of true chronology, or even removed altogether. Subversion's ability to correctly convert revision dates into real revision numbers depends on revision datestamps maintaining a sequential ordering—the younger the revision, the younger its timestamp. If this ordering isn't maintained, you will likely find that trying to use dates to specify revision ranges in your repository doesn't always return the data you might have expected.

          ...and this... (on the same page)

          Is Subversion a Day Early?

          If you specify a single date as a revision without specifying a time of day (for example 2006-11-27), you may think that Subversion should give you the last revision that took place on the 27th of November. Instead, you'll get back a revision from the 26th, or even earlier. Remember that Subversion will find the most recent revision of the repository as of the date you give. If you give a date without a timestamp, such as 2006-11-27, Subversion assumes a time of 00:00:00, so looking for the most recent revision won't return anything on the 27th.

          If you want to include the 27th in your search, you can either specify the 27th with the time (

          {"2006-11-27 23:59"}

          ), or just specify the next day (

          {2006-11-28}

          ).

          so, I believe, using time/date stamps is not the best and most reliable approach to make a decision for a build nor it will correctly update your working space.

          regards,
          Slava

          Slava Maslenitsyn added a comment - just FYI: http://svnbook.red-bean.com/en/1.7/svn.tour.revs.specifiers.html Since the timestamp of a revision is stored as an unversioned, modifiable property of the revision (see the section called “Properties”), revision timestamps can be changed to represent complete falsifications of true chronology, or even removed altogether. Subversion's ability to correctly convert revision dates into real revision numbers depends on revision datestamps maintaining a sequential ordering—the younger the revision, the younger its timestamp. If this ordering isn't maintained, you will likely find that trying to use dates to specify revision ranges in your repository doesn't always return the data you might have expected. ...and this... (on the same page) Is Subversion a Day Early? If you specify a single date as a revision without specifying a time of day (for example 2006-11-27), you may think that Subversion should give you the last revision that took place on the 27th of November. Instead, you'll get back a revision from the 26th, or even earlier. Remember that Subversion will find the most recent revision of the repository as of the date you give. If you give a date without a timestamp, such as 2006-11-27, Subversion assumes a time of 00:00:00, so looking for the most recent revision won't return anything on the 27th. If you want to include the 27th in your search, you can either specify the 27th with the time ( {"2006-11-27 23:59"} ), or just specify the next day ( {2006-11-28} ). so, I believe, using time/date stamps is not the best and most reliable approach to make a decision for a build nor it will correctly update your working space. regards, Slava

          kutzi added a comment -

          Okay the 2nd paragraph is no big deal - it just says that the time defaults to 0 hour if you don't specify it.
          About the 1st paragraph: so what is the point you want to make? That if you really want to mess with the timestamp, you can.
          Yeah okay, you may, but I don't think that's something 'sane' to do.

          Let me tell you how I see it:

          • Jenkins has been using timestamps in the svn-plugin for a very long time. This has worked well for the big majority of users. There's an occasional bug report about 'wrong updates' which almost always has something to do with out-of-sync clocks and so easily resolved.
          • for some reason it is not working for you. Maybe because you messed with the timestamps. That's IMO a problem with your configuration and no bug in the svn-plugin
          • if you have a better idea on how to handle updates in the svn-plugin, feel free to post your concrete idea (loose ideas to work with revisions instead of timestamps have already been posted before. They're IMHO no big help) - i.e. as a Github pull request. However, I think that the danger of introducing backwards incompatible changes by this is IMO very very big. So we would need to introduce it as an optional setting. Which would in turn bring up the question why we need this setting, when the plugin is working very well in the vast majority of environments ...

          BTW: you may also want to experiment with the @HEAD setting in the repository URLs

          kutzi added a comment - Okay the 2nd paragraph is no big deal - it just says that the time defaults to 0 hour if you don't specify it. About the 1st paragraph: so what is the point you want to make? That if you really want to mess with the timestamp, you can. Yeah okay, you may, but I don't think that's something 'sane' to do. Let me tell you how I see it: Jenkins has been using timestamps in the svn-plugin for a very long time. This has worked well for the big majority of users. There's an occasional bug report about 'wrong updates' which almost always has something to do with out-of-sync clocks and so easily resolved. for some reason it is not working for you. Maybe because you messed with the timestamps. That's IMO a problem with your configuration and no bug in the svn-plugin if you have a better idea on how to handle updates in the svn-plugin, feel free to post your concrete idea (loose ideas to work with revisions instead of timestamps have already been posted before. They're IMHO no big help) - i.e. as a Github pull request. However, I think that the danger of introducing backwards incompatible changes by this is IMO very very big. So we would need to introduce it as an optional setting. Which would in turn bring up the question why we need this setting, when the plugin is working very well in the vast majority of environments ... BTW: you may also want to experiment with the @HEAD setting in the repository URLs

          Hello,
          First of all… I am not your enemy… so words about loose ideas to work with revision instead of timestamps… “you messed up with timestamps” … perhaps not so nice…
          Anyway…
          1. I think you are mistaken. What this lines are saying is: when subversion cannot fully read and understand the timestamp, but understands it partially, it assumes that time is 00:00 (midnight) of that day. You, in your request may not mean it, right?
          2. I did not delete any timestamps. I checked all the repos I am administering several thousand revisions back – all timestamps are there. Yes, they can be changed. I personally never did it for any single timestamp in any repo I am administering. Users…. might however.
          3. I made my point clear many times already – timestamp are difficult to deal with and they cannot be reliable in making decision whether or not to run build. Besides, it is not efficient to use timestamp to search repo if any revision were made for this particular place in repo between these two timestamps – too much work… revisions are better and more clear defined properties to deal with, so I am proposing to make changes in the code and get rid of this approach with timestamps and use revision numbers instead.

          Regards,
          Slava

          Slava Maslenitsyn added a comment - Hello, First of all… I am not your enemy… so words about loose ideas to work with revision instead of timestamps… “you messed up with timestamps” … perhaps not so nice… Anyway… 1. I think you are mistaken. What this lines are saying is: when subversion cannot fully read and understand the timestamp, but understands it partially, it assumes that time is 00:00 (midnight) of that day. You, in your request may not mean it, right? 2. I did not delete any timestamps. I checked all the repos I am administering several thousand revisions back – all timestamps are there. Yes, they can be changed. I personally never did it for any single timestamp in any repo I am administering. Users…. might however. 3. I made my point clear many times already – timestamp are difficult to deal with and they cannot be reliable in making decision whether or not to run build. Besides, it is not efficient to use timestamp to search repo if any revision were made for this particular place in repo between these two timestamps – too much work… revisions are better and more clear defined properties to deal with, so I am proposing to make changes in the code and get rid of this approach with timestamps and use revision numbers instead. Regards, Slava

          kutzi added a comment - - edited

          (I know that you're not my 'enemy'. If I wrote some words which you consider insulting, I'm sorry for this)

          Re 1: No, that's definitely not what the 2nd paragraph says.

          Re 2: Okay, so someone in your organisation may have messed with the timestamps. Or not. After all I'm not really convinced that timestamps are your problem. At least I didn't see any conclusive hint in the stacktrace of it.

          Re 3: what I wanted to say with 'loose ideas': inconcrete ideas ('lets use revisions instead of timestamps') have been expressed before (just search JIRA for duplicates). It doesn't help if you say it again. Please concrete your idea by a pull request, if you think the change is really necessary (I don't think so)

          kutzi added a comment - - edited (I know that you're not my 'enemy'. If I wrote some words which you consider insulting, I'm sorry for this) Re 1: No, that's definitely not what the 2nd paragraph says. Re 2: Okay, so someone in your organisation may have messed with the timestamps. Or not. After all I'm not really convinced that timestamps are your problem. At least I didn't see any conclusive hint in the stacktrace of it. Re 3: what I wanted to say with 'loose ideas': inconcrete ideas ('lets use revisions instead of timestamps') have been expressed before (just search JIRA for duplicates). It doesn't help if you say it again. Please concrete your idea by a pull request, if you think the change is really necessary (I don't think so)

          ok.
          sorry... I don't know your name...
          alright. let's assume it is not a svnkit problem.
          then explain to me please, how come, when we get this 500 error (which are getting from time to time, and when it is happening it is always when svnkit is trying to update working space with timestamp), and when build engineer by suggestion, runs build manually using mvn, this build goes just fine.
          so, it means svn itself is ok. code is fine... and only third party is left here... svnkit.
          or perhaps you another explanation?
          you also said I am not the first one, who is reporting this problem.
          you also have to admit, that this approach to calculate difference in the working space based on timestamp is not very much efficient. too much work, which takes too much time.
          and honestly, I don't understand why this approach has been chosen at all? it is very natural just to obtain revision before "svn update" then run "svn update" then obtain revision and compare them.
          or, like I suggested - even more simple. calculate working space used. run svn update. calculate used space again. which could be even faster, as you go to svn repo just once.
          like I said - i believe playing with time is not the best thing at all... time is not reliable property at all. two machines on the network will never have the same timestamp. besides... let me ask you - up to what precision you are requesting time in the code? and what precision machine gives on the request? and what precision returned by svn?
          perhaps he could a problem too? what do you think?
          but, in general, again - I think using timestamp is not reliable and too complicated.
          I am mechanical engineer by education... simpler mechanism - more reliable it is.
          cheers,
          Slava

          Slava Maslenitsyn added a comment - ok. sorry... I don't know your name... alright. let's assume it is not a svnkit problem. then explain to me please, how come, when we get this 500 error (which are getting from time to time, and when it is happening it is always when svnkit is trying to update working space with timestamp), and when build engineer by suggestion, runs build manually using mvn, this build goes just fine. so, it means svn itself is ok. code is fine... and only third party is left here... svnkit. or perhaps you another explanation? you also said I am not the first one, who is reporting this problem. you also have to admit, that this approach to calculate difference in the working space based on timestamp is not very much efficient. too much work, which takes too much time. and honestly, I don't understand why this approach has been chosen at all? it is very natural just to obtain revision before "svn update" then run "svn update" then obtain revision and compare them. or, like I suggested - even more simple. calculate working space used. run svn update. calculate used space again. which could be even faster, as you go to svn repo just once. like I said - i believe playing with time is not the best thing at all... time is not reliable property at all. two machines on the network will never have the same timestamp. besides... let me ask you - up to what precision you are requesting time in the code? and what precision machine gives on the request? and what precision returned by svn? perhaps he could a problem too? what do you think? but, in general, again - I think using timestamp is not reliable and too complicated. I am mechanical engineer by education... simpler mechanism - more reliable it is. cheers, Slava

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

              Created:
              Updated: