[JIRA] [email-ext] (JENKINS-18517) Content token reference help bubble evaluated multiple times on Job Configuration page
pancake commented on JENKINS-18517 Content token reference help bubble evaluated multiple times on Job Configuration page We have the same problem on Jenkins 1.509.1 emailext 2.30.2 token-macro 1.7. Job configuration page is currently ~50 Mb because of that and takes a while to load. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [subversion] (JENKINS-13835) E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request
pancake
commented on JENKINS-13835
E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request
Greg, the problem is indeed on the Jenkins side. Not necessarily on Jenkins server itself. Basically speaking this glitch occurs when svn client (Jenkins server or slave) stops communicating to svn server for unexpectedly long time (KeepAlive). In our Jenkins deployment we saw that svn checkout on slave consumed 100% of one CPU core, i.e. checkout speed was limited by per-core performance of Jenkins node. So, to workaround the alleviate the situation you can:
See if CPU/disk performance is a bottleneck for svn checkout and upgrade the hardware of relevant Jenkins node.
Tune Jenkins GC options. We didn't check, but it's very likely that delays are due to GC.
Increase KeepAlive on svn server. You'll probably want to setup a dedicated svn mirror for Jenkins and set KeepAlive on that mirror only. That's not good to have insanely big KeepAlive on a publicly available servers.
Note that we're using 1.6 WC format on Jenkins ("Manage Jenkins" "Configure System" "Subversion"). I don't quite remember what exactly bug made us downgrade 1.7 - 1.6 and not even sure if it's still there. But you can try it if the above doesn't help.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [subversion] (JENKINS-13835) E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request
pancake commented on JENKINS-13835 E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request Greg, it should be minutes or even tens of minutes (depends on WC size and hardware of the box that performs the checkout). Jenkins' KeepAlive has nothing to do with the problem. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-18320) Nested processes aren't killed on win2003R2+
pancake created JENKINS-18320 Nested processes arent killed on win2003R2+ Issue Type: Bug Assignee: Unassigned Components: core Created: 12/Jun/13 5:15 PM Description: Processes nested by a build aren't killed on Windows OSes newer than win2003R2: win2008R2 and win2012. When the same project is run on win2003r2/Linux slaves everything works just fine. Environment: Jenkins ver. 1.509.1. Server: CentOS 6.3 x64, Oracle JRE 1.7.0_04. Still reproduces after switching server to OpenJDK 1.7.0.19.x86_64. Reproduces slaves: - win2008R2 x86_64 (uses Oracle JRE 1.7.0_17 x86_64); - win2012 x86_64 (uses Oracle JRE 1.7.0_17 x86_64). Does not reproduce on slaves; - win2003r2 x86_64 (uses Oracle JRE 1.7.0_10 x86_64); - win2003r2 x86_32 (uses Oracle JRE 1.7.0_06); - Linux slaves. Project: Jenkins Labels: ProcessTreeKiller Priority: Major Reporter: pancake This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [findbugs] (JENKINS-17949) Parsing FindBugs report hangs sometimes
pancake commented on JENKINS-17949 Parsing FindBugs report hangs sometimes Still reproduces after migrating server to java-1.7.0-openjdk-1.7.0.19.x86_64. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [build-timeout] (JENKINS-18294) Build time-out should also apply to post-build actions
pancake created JENKINS-18294 Build time-out should also apply to post-build actions Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: build-timeout Created: 11/Jun/13 2:47 PM Description: Our builds hang forever even though we have enabled "Abort the build if it's stuck" with "Timeout minutes" = 50. This is because the job hangs during post-build actions (see JENKINS-17949). Jobs that hang on one of the Build steps are terminated properly by the plugin. Please make the time taken by post-build actions count towards the configured time limit. If one of post-build actions exceeds the timeout, the build should be terminated. p.s. We use version 1.8 of the Build-timeout Plugin. According to History there is no such a feature even in the last version. Project: Jenkins Priority: Major Reporter: pancake This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-18010) IOException: Insufficient system resources... when archiving artifacts
pancake created JENKINS-18010 IOException: Insufficient system resources... when archiving artifacts Issue Type: Bug Assignee: Unassigned Components: core Created: 20/May/13 11:54 AM Description: This started occurring sometimes after upgrading Jenkins ver. 1.480.1 - 1.509.1. ERROR: Failed to archive artifacts: ... hudson.util.IOException2: hudson.util.IOException2: Failed to extract ... at hudson.FilePath.readFromTar(FilePath.java:2014) at hudson.FilePath.copyRecursiveTo(FilePath.java:1926) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:137) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:774) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:724) at hudson.model.Run.execute(Run.java:1600) 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: unexpected EOF with 3584 bytes unread at hudson.org.apache.tools.tar.TarInputStream.read(TarInputStream.java:349) at java.io.FilterInputStream.read(FilterInputStream.java:107) at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1025) at org.apache.commons.io.IOUtils.copy(IOUtils.java:999) at hudson.util.IOUtils.copy(IOUtils.java:37) at hudson.FilePath.readFromTar(FilePath.java:2004) ... 11 more at hudson.FilePath.copyRecursiveTo(FilePath.java:1933) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:137) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:774) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:724) at hudson.model.Run.execute(Run.java:1600) 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.util.concurrent.ExecutionException: java.io.IOException: Insufficient system resources exist to complete the requested service at hudson.remoting.Channel$4.adapt(Channel.java:705) at hudson.remoting.Channel$4.adapt(Channel.java:700) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59) at hudson.FilePath.copyRecursiveTo(FilePath.java:1929) ... 10 more Caused by: java.io.IOException: Insufficient system resources exist to complete the requested service at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(Unknown Source) at hudson.util.io.TarArchiver.visit(TarArchiver.java:114) at hudson.util.DirScanner$Glob.scan(DirScanner.java:133) at hudson.FilePath.writeToTar(FilePath.java:1978) at hudson.FilePath.access$1000(FilePath.java:168) at hudson.FilePath$36.invoke(FilePath.java:1919) at hudson.FilePath$36.invoke(FilePath.java:1915) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2387) 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(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Environment: Jenkins ver. 1.509.1, Copy Artifact Plugin 1.25. Server: CentOS 6.3 x64, jre 1.7.0_04.
[JIRA] [findbugs] (JENKINS-17949) Parsing FindBugs report hangs sometimes
pancake created JENKINS-17949 Parsing FindBugs report hangs sometimes Issue Type: Bug Assignee: Ulli Hafner Components: findbugs Created: 14/May/13 1:25 PM Description: I've just discovered that one of our builds was hanging for 19 hours. Last line of build log is: FINDBUGS Collecting findbugs analysis files... Slave treads: "Attach Listener" daemon prio=5 RUNNABLE "Channel reader thread: channel" prio=5 RUNNABLE java.net.SocketInputStream.socketRead0(Native Method) java.net.SocketInputStream.read(Unknown Source) java.net.SocketInputStream.read(Unknown Source) java.io.FilterInputStream.read(Unknown Source) java.io.BufferedInputStream.fill(Unknown Source) java.io.BufferedInputStream.read(Unknown Source) java.io.ObjectInputStream$PeekInputStream.peek(Unknown Source) java.io.ObjectInputStream$BlockDataInputStream.peek(Unknown Source) java.io.ObjectInputStream$BlockDataInputStream.peekByte(Unknown Source) java.io.ObjectInputStream.readObject0(Unknown Source) java.io.ObjectInputStream.readObject(Unknown Source) hudson.remoting.Command.readFrom(Command.java:92) hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59) hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) "Finalizer" daemon prio=8 WAITING java.lang.Object.wait(Native Method) java.lang.ref.ReferenceQueue.remove(Unknown Source) java.lang.ref.ReferenceQueue.remove(Unknown Source) java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source) "main" prio=5 WAITING java.lang.Object.wait(Native Method) java.lang.Object.wait(Object.java:503) hudson.remoting.Channel.join(Channel.java:800) hudson.remoting.Launcher.main(Launcher.java:484) hudson.remoting.Launcher.runOnSocket(Launcher.java:375) hudson.remoting.Launcher.runAsTcpServer(Launcher.java:365) hudson.remoting.Launcher.run(Launcher.java:218) hudson.remoting.Launcher.main(Launcher.java:180) "Ping thread for channel hudson.remoting.Channel@bebb88:channel" daemon prio=5 TIMED_WAITING java.lang.Thread.sleep(Native Method) hudson.remoting.PingThread.run(PingThread.java:86) "Ping thread for channel hudson.remoting.Channel@bebb88:channel" daemon prio=5 TIMED_WAITING java.lang.Thread.sleep(Native Method) hudson.remoting.PingThread.run(PingThread.java:86) "Pipe writer thread: channel" prio=5 WAITING sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.park(Unknown Source) java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source) java.util.concurrent.LinkedBlockingQueue.take(Unknown Source) java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source) java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) java.lang.Thread.run(Unknown Source) "pool-1-svnkit-thread-1" daemon prio=5 WAITING sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.park(Unknown Source) java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Unknown Source) java.util.concurrent.SynchronousQueue$TransferStack.transfer(Unknown Source) java.util.concurrent.SynchronousQueue.take(Unknown Source) java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source) java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) java.lang.Thread.run(Unknown Source) "pool-1-svnkit-thread-2" daemon prio=5 WAITING sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.park(Unknown Source) java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(Unknown Source) java.util.concurrent.SynchronousQueue$TransferStack.transfer(Unknown Source) java.util.concurrent.SynchronousQueue.take(Unknown Source) java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source) java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) java.lang.Thread.run(Unknown Source) "pool-1-thread-1965" prio=5 RUNNABLE
[JIRA] [findbugs] (JENKINS-17949) Parsing FindBugs report hangs sometimes
pancake commented on JENKINS-17949 Parsing FindBugs report hangs sometimes After cancelling the build this was logged: FINDBUGS null ...and then other postbuild steps were executed. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [copyartifact] (JENKINS-17950) Allow copying artifacts from last (even failed) build
pancake created JENKINS-17950 Allow copying artifacts from last (even failed) build Issue Type: New Feature Assignee: Unassigned Components: copyartifact Created: 14/May/13 3:28 PM Description: I'd like to be able to copy artifacts from last completed build, both successful and failed. Currently there is no way to achieve that with Copy Artifact Plugin. Environment: Copy Artifact Plugin 1.25 Project: Jenkins Priority: Major Reporter: pancake This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-7813) Archiving artifacts very slow
pancake commented on JENKINS-7813 Archiving artifacts very slow @stephenconnolly: thanks! What do we need to upgrade to get those performance improvements? Is it Jenkins itself? Will the optimization be merged into LTS? Is there a way to find out such thing ourselves (from GitHug Commit History?) instead of bothering developers? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-17388) ssh-slaves 0.23: NoSuchMethodException: com.trilead.ssh2.Session.setWindowSize(int)
pancake created JENKINS-17388 ssh-slaves 0.23: NoSuchMethodException: com.trilead.ssh2.Session.setWindowSize(int) Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: ssh-slaves Created: 27/Mar/13 3:34 PM Description: After updating SSH Slaves plugin to 0.23 we get this when slave is starting: [03/27/13 10:07:14] [SSH] Checking java version of /home/hudson/JDK_HOME_1_6_0/bin/java [03/27/13 10:07:15] [SSH] /home/hudson/JDK_HOME_1_6_0/bin/java -version returned 1.6.0_16. [03/27/13 10:07:15] [SSH] Starting sftp client. [03/27/13 10:07:15] [SSH] Copying latest slave.jar... [03/27/13 10:07:15] [SSH] Copied 278,201 bytes. ERROR: Failed to expand buffer size java.lang.NoSuchMethodException: com.trilead.ssh2.Session.setWindowSize(int) at java.lang.Class.getMethod(Class.java:1622) at hudson.plugins.sshslaves.SSHLauncher.expandChannelBufferSize(SSHLauncher.java:711) at hudson.plugins.sshslaves.SSHLauncher.startSlave(SSHLauncher.java:661) at hudson.plugins.sshslaves.SSHLauncher.launch(SSHLauncher.java:472) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:200) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) [03/27/13 10:07:15] [SSH] Starting slave process: cd '/home/hudson/HUDSON_HOME' /home/hudson/JDK_HOME_1_6_0/bin/java -Xmx1024m -XX:HeapDumpPath=/home/hudson/HUDSON_HOME/_dumps/ -jar slave.jar ===[JENKINS REMOTING CAPACITY]===channel started Slave.jar version: 2.17 This is a Unix slave Copied maven-agent.jar Copied maven3-agent.jar Copied maven3-interceptor.jar Copied maven-interceptor.jar Copied maven2.1-interceptor.jar Copied plexus-classworld.jar Copied classworlds.jar Evacuated stdout Slave successfully connected and online We had to downgrade to SSH Slaves plugin to 0.22, which resolved the problem: [03/27/13 10:16:32] [SSH] Checking java version of /home/hudson/JDK_HOME_1_6_0/bin/java [03/27/13 10:16:33] [SSH] /home/hudson/JDK_HOME_1_6_0/bin/java -version returned 1.6.0_16. [03/27/13 10:16:33] [SSH] Starting sftp client. [03/27/13 10:16:33] [SSH] Copying latest slave.jar... [03/27/13 10:16:33] [SSH] Copied 278,201 bytes. [03/27/13 10:16:33] [SSH] Starting slave process: cd '/home/hudson/HUDSON_HOME' /home/hudson/JDK_HOME_1_6_0/bin/java -Xmx1024m -XX:HeapDumpPath=/home/hudson/HUDSON_HOME/_dumps/ -jar slave.jar ===[JENKINS REMOTING CAPACITY]===channel started Slave.jar version: 2.17 This is a Unix slave Copied maven-agent.jar Copied maven3-agent.jar Copied maven3-interceptor.jar Copied maven-interceptor.jar Copied maven2.1-interceptor.jar Copied plexus-classworld.jar Copied classworlds.jar Evacuated stdout Slave successfully connected and online BTW, during this upgrade...downgrade process SSH slave credentials somehow got reset: [03/27/13 10:14:02] [SSH] Opening SSH connection to jenkins-l64b.ourcompany.com:22. [03/27/13 10:14:02] [SSH] Authenticating as jenkins/**. [03/27/13 10:14:02] [SSH] Authentication failed. hudson.AbortException: Authentication failed. at hudson.plugins.sshslaves.SSHLauncher.openConnection(SSHLauncher.java:753) at hudson.plugins.sshslaves.SSHLauncher.launch(SSHLauncher.java:278) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:200) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) [03/27/13 10:14:02] [SSH] Connection closed. We've been using hudson/jenkins for many years and had to switch to LTS since so called "normal" version would get broken in 95%+ of all plugin/Jenkins updates. And now we observe similar problem with LTS. I guess many Jenkins users would agree with
[JIRA] (JENKINS-17388) ssh-slaves 0.23: NoSuchMethodException: com.trilead.ssh2.Session.setWindowSize(int)
pancake commented on JENKINS-17388 ssh-slaves 0.23: NoSuchMethodException: com.trilead.ssh2.Session.setWindowSize(int) JIC: if SSH Slaves plugin 0.23 is incompatible with LTS 1.480.3, I expect to see this in Jenkins Plugin Manager: Warning: This plugin is built for Jenkins X.Y.Z or newer. It may or may not work in your Jenkins. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-13835) E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request
pancake commented on JENKINS-13835 E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request dlavelle, these settings work for us: Jenkins 1.480.3 LTS Subversion Plugin version 1.45 Subversion Workspace Version = 1.6 (svn:externals to file) KeepAliveTimeout 60 in httpd.conf The only problem that we sometimes experience is this when performing big checkouts (~1.5 Gb, ~40 K files): [...truncated 2840 lines...] Caused by: svn: E175002: REPORT request failed on '/svn/svnLatest/!svn/vcc/default' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:752) ... 30 more Caused by: svn: E175002: Connection reset at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:109) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:507) ... 30 more Caused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at org.tmatesoft.svn.core.internal.util.ChunkedInputStream.getChunkSizeFromInputStream(ChunkedInputStream.java:111) at org.tmatesoft.svn.core.internal.util.ChunkedInputStream.nextChunk(ChunkedInputStream.java:97) at org.tmatesoft.svn.core.internal.util.ChunkedInputStream.read(ChunkedInputStream.java:69) at sun.nio.cs.StreamDecoder.readBytes(Unknown Source) at sun.nio.cs.StreamDecoder.implRead(Unknown Source) at sun.nio.cs.StreamDecoder.read(Unknown Source) at java.io.InputStreamReader.read(Unknown Source) at org.tmatesoft.svn.core.internal.io.dav.http.XMLReader.read(XMLReader.java:39) at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source) at org.apache.xerces.impl.XMLEntityScanner.scanContent(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanContent(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:869) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:834) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:218) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:460) ... 30 more FATAL: null java.lang.NullPointerException at java.util.ArrayList.addAll(ArrayList.java:530) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:843) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:781) at hudson.model.AbstractProject.checkout(AbstractProject.java:1256) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494) at hudson.model.Run.execute(Run.java:1502) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you
[JIRA] (JENKINS-15300) StringIndexOutOfBounds
pancake commented on JENKINS-15300 StringIndexOutOfBounds We have exactly them same after scm-sync-configuration upgrade from 0.0.5 to 0.0.6. We use Jenkins ver. 1.479 @ Sun JRE 7u6 @ x64 Win2003 R2. Had to manually downgrade to 0.0.5 from http://updates.jenkins-ci.org/download/plugins/scm-sync-configuration/ Oct 01, 2012 8:25:42 AM jenkins.InitReactorRunner$1 onTaskFailed SEVERE: Failed Loading plugin scm-sync-configuration hudson.util.IOException2: Unable to load hudson.plugins.scm_sync_configuration.ScmSyncConfigurationPlugin from scm-sync-configuration at hudson.ClassicPluginStrategy.load(ClassicPluginStrategy.java:332) at hudson.PluginManager$2$1$1.run(PluginManager.java:317) at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259) at jenkins.model.Jenkins$7.runTask(Jenkins.java:879) at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187) at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.ExceptionInInitializerError at hudson.plugins.scm_sync_configuration.ScmSyncConfigurationPlugin.clinit(ScmSyncConfigurationPlugin.java:46) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:525) at java.lang.Class.newInstance0(Class.java:372) at java.lang.Class.newInstance(Class.java:325) at hudson.ClassicPluginStrategy.load(ClassicPluginStrategy.java:326) ... 9 more Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 1 at java.lang.String.charAt(String.java:658) at java.util.regex.Matcher.appendReplacement(Matcher.java:762) at java.util.regex.Matcher.replaceAll(Matcher.java:906) at java.lang.String.replaceAll(String.java:2162) at hudson.plugins.scm_sync_configuration.strategies.model.PatternsEntityMatcher$1.apply(PatternsEntityMatcher.java:20) at hudson.plugins.scm_sync_configuration.strategies.model.PatternsEntityMatcher$1.apply(PatternsEntityMatcher.java:18) at com.google.common.collect.Iterators$8.next(Iterators.java:812) at java.util.AbstractCollection.toArray(AbstractCollection.java:188) at hudson.plugins.scm_sync_configuration.strategies.model.PatternsEntityMatcher.init(PatternsEntityMatcher.java:27) at hudson.plugins.scm_sync_configuration.strategies.model.ClassAndFileConfigurationEntityMatcher.init(ClassAndFileConfigurationEntityMatcher.java:13) at hudson.plugins.scm_sync_configuration.strategies.impl.JobConfigScmSyncStrategy.clinit(JobConfigScmSyncStrategy.java:29) ... 17 more Oct 01, 2012 8:25:42 AM jenkins.InitReactorRunner$1 onAttained INFO: Prepared all plugins Oct 01, 2012 8:25:48 AM jenkins.InitReactorRunner$1 onTaskFailed SEVERE: Failed Initializing plugin scm-sync-configuration java.lang.NullPointerException at hudson.PluginManager$2$1$2.run(PluginManager.java:333) at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259) at jenkins.model.Jenkins$7.runTask(Jenkins.java:879) at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187) at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Oct 01, 2012 8:25:48 AM jenkins.InitReactorRunner$1 onAttained INFO: Started all plugins This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15285) scm-sync-configuration upgrade from 0.0.5 to 0.0.6 results in NullPointerException
pancake commented on JENKINS-15285 scm-sync-configuration upgrade from 0.0.5 to 0.0.6 results in NullPointerException See JENKINS-15300 for more info. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15300) StringIndexOutOfBounds
pancake closed JENKINS-15300 as Duplicate StringIndexOutOfBounds Duplicates JENKINS-15285 "scm-sync-configuration upgrade from 0.0.5 to 0.0.6 results in NullPointerException". Change By: pancake (01/Oct/12 2:01 PM) Status: Open Closed Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13835) upgrading Subversion Plugin to 1.40 totally ruined our CI server
[
https://issues.jenkins-ci.org/browse/JENKINS-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163593#comment-163593
]
pancake commented on JENKINS-13835:
---
*stephenconnolly*, E175002 doesn't seem to be related to server encoding issue.
The bug occurred totally sporadically, i.e. didn't always reproduce for the
same job (hence the same repo URL). In case that was caused by something wrong
with repository, it should have been always reproducible for the same URL,
right?
*Luca*, there is a workaround for not a working copy issue: go to Jenkins
configuration and change WC format to 1.6. And E175002 never reproduced for me
after downgrading 1.40 - 1.39.
upgrading Subversion Plugin to 1.40 totally ruined our CI server
Key: JENKINS-13835
URL: https://issues.jenkins-ci.org/browse/JENKINS-13835
Project: Jenkins
Issue Type: Bug
Components: subversion
Environment: Jenkins ver. 1.460; Subversion Plugin ver. 1.40, 1.39;
Windows Server 2003 R2 x64 SP2; Subversion server ver. 1.6.16.
Reporter: pancake
Labels: linux, plugin, subversion, windows
Updating Subversion Plugin to 1.40 caused multiple bugs. Rolling back to 1.39
resulted to {color:red}complete inability to perform a checkout. CI server is
totally unusable now.{color}
*Issue #1*
After updating to Subversion Plugin to 1.40 (from 1.39) this exception
started occurring _sometimes_ (various salves, various jobs):
{quote}
Checking out a fresh workspace because there's no workspace at
C:\_JenkinsCI\workspace\XXX
Cleaning local Directory .
Checking out http://oursvnserver/svn/svnLatest/.../XXX
A ...
ERROR: Failed to check out http://oursvnserver/svn/svnLatest/.../XXX
org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT
/svn/svnLatest/!svn/vcc/default failed
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:304)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:289)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:277)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:696)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:328)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:216)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:100)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:756)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:14)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:9)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
at
org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:781)
at
hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:85)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:152)
at
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
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
[JIRA] (JENKINS-13835) upgrading Subversion Plugin to 1.40 totally ruined our CI server
[
https://issues.jenkins-ci.org/browse/JENKINS-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pancake updated JENKINS-13835:
--
Priority: Major (was: Blocker)
Found workaround for *Issue #3*: set svn wc format to 1.6 in Jenkins
configuration.
After downgrading Subversion Plugin value 1.4 was shown for svn wc format on
Jenkins configuration page.
Note I've set it to 1.7 after uprading to Subversion Plugin ver. 1.40.
I.e. either actual value 1.7 of wc format was rendered (and treated)
incorrectly or Subversion Plugin ver. 1.39 can't work with wc format 1.4.
I'm now decreasing issue priority to blocker \- major since our CI server
can function properly due to the workaround. The issues *#1* and *#2* still
prevent us from upgrading to Subversion Plugin ver. 1.40.
upgrading Subversion Plugin to 1.40 totally ruined our CI server
Key: JENKINS-13835
URL: https://issues.jenkins-ci.org/browse/JENKINS-13835
Project: Jenkins
Issue Type: Bug
Components: subversion
Environment: Jenkins ver. 1.460; Subversion Plugin ver. 1.40, 1.39;
Windows Server 2003 R2 x64 SP2; Subversion server ver. 1.6.16.
Reporter: pancake
Labels: plugin, subversion, windows
Updating Subversion Plugin to 1.40 caused multiple bugs. Rolling back to 1.39
resulted to {color:red}complete inability to perform a checkout. CI server is
totally unusable now.{color}
*Issue #1*
After updating to Subversion Plugin to 1.40 (from 1.39) this exception
started occurring _sometimes_ (various salves, various jobs):
{quote}
Checking out a fresh workspace because there's no workspace at
C:\_JenkinsCI\workspace\XXX
Cleaning local Directory .
Checking out http://oursvnserver/svn/svnLatest/.../XXX
A ...
ERROR: Failed to check out http://oursvnserver/svn/svnLatest/.../XXX
org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT
/svn/svnLatest/!svn/vcc/default failed
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:304)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:289)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:277)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:696)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:328)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:216)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:100)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:756)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:14)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:9)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
at
org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:781)
at
hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:85)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:152)
at
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at
[JIRA] (JENKINS-13835) upgrading Subversion Plugin to 1.40 totally ruined our CI server
pancake created JENKINS-13835:
-
Summary: upgrading Subversion Plugin to 1.40 totally ruined our CI
server
Key: JENKINS-13835
URL: https://issues.jenkins-ci.org/browse/JENKINS-13835
Project: Jenkins
Issue Type: Bug
Components: subversion
Environment: Jenkins ver. 1.460; Subversion Plugin 1.40, 1.39; Windows
Server 2003 R2 x64 SP2
Reporter: pancake
Priority: Blocker
Updating Subversion Plugin to 1.40 caused multiple bugs. Rolling back to 1.39
resulted to {color:red}complete inability to perform a checkout. CI server is
totally unusable now.{color}
*Issue #1*
After updating to Subversion Plugin to 1.40 (from 1.39) this exception started
occurring _sometimes_ (various salves, various jobs):
{quote}
Checking out a fresh workspace because there's no workspace at
C:\_JenkinsCI\workspace\XXX
Cleaning local Directory .
Checking out http://oursvnserver/svn/svnLatest/.../XXX
A ...
ERROR: Failed to check out http://oursvnserver/svn/svnLatest/.../XXX
org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT
/svn/svnLatest/!svn/vcc/default failed
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:304)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:289)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:277)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:696)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:328)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:216)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:100)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:756)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:14)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:9)
at
org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
at
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
at
org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:781)
at
hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:85)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:152)
at
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
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 /svn/svnLatest/!svn/vcc/default failed
at
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
... 35 more
FATAL: null
java.lang.NullPointerException
{quote}
*Issue #2*
{{Emulate clean checkout by first deleting unversioned/ignored files, then 'svn
update'}} no longer deletes unversioned files in 1.40.
*Issue #3*
Because of #2 and #3 I've decided to roll back to 1.39. So, I've
