FilePath.copyTo throws NoSuchMethodError exception after upgrading Hudson

[John Borghi]

Hi,

In the log-parser plugin I am seeing the following "NoSuchMethodError" being thrown after upgrade from Hudson 1.393 to Jenkins 1.404

From the trace, it appears the FilePath.copyTo() method is internally trying to call the hudson.remoting.VirtualChannel.syncLocalIO method. The docs say this method was introduced in 1.402.

Does this mean the FilePath.copyTo() method used in plugins built against prior versions of Hudson (this plugin uses 1.350 as the parent) makes the plugins incompatible with newer Jenkins versions? Any suggestions greatly appreciated!

Thanks,
John

java.io.IOException: Remote call on cronewel-s21 failed
        at hudson.remoting.Channel.call(Channel.java:639)
        at hudson.plugins.logparser.LogParserStatusComputer.computeStatusMatches(LogParserStatusComputer.java:40)
        at hudson.plugins.logparser.LogParserStatusComputer.<init>(LogParserStatusComputer.java:33)
        at hudson.plugins.logparser.LogParserParser.parseLogBody(LogParserParser.java:275)
        at hudson.plugins.logparser.LogParserParser.parseLog(LogParserParser.java:114)
        at hudson.plugins.logparser.LogParserPublisher.perform(LogParserPublisher.java:54)
        at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
        at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:649)
        at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:625)
        at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:603)
        at hudson.model.Build$RunnerImpl.post2(Build.java:161)
        at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:572)
        at hudson.model.Run.run(Run.java:1386)
        at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
        at hudson.model.ResourceController.execute(ResourceController.java:88)
        at hudson.model.Executor.run(Executor.java:145)
Caused by: java.lang.NoSuchMethodError: hudson.remoting.VirtualChannel.syncLocalIO()V
        at hudson.FilePath.copyTo(FilePath.java:1411)
        at hudson.FilePath.copyTo(FilePath.java:1370)
        at hudson.plugins.logparser.LogParserStatusComputer.computeStatusMatches(LogParserStatusComputer.java:79)
        at hudson.plugins.logparser.LogParserStatusComputer.access$000(LogParserStatusComputer.java:23)
        at hudson.plugins.logparser.LogParserStatusComputer$1.call(LogParserStatusComputer.java:45)
        at hudson.plugins.logparser.LogParserStatusComputer$1.call(LogParserStatusComputer.java:40)
        at hudson.remoting.UserRequest.perform(UserRequest.java:104)
        at hudson.remoting.UserRequest.perform(UserRequest.java:48)
        at hudson.remoting.Request$2.run(Request.java:270)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
        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:619)

[Kohsuke Kawaguchi]

This is because slave.jar on this slave is out of sync from the master.
This can happen, for example, if you tell Jenkins to launch a slave via
your custom script.

The typical trick is to make your script wget slave.jar from
http://server/jnlpJars/slave.jar and copy it to your slave, then to run it.

With that said, users are supposed to be lazy, so I just committed the
code so that the core will tolerate this error and handle it more
gracefully.

> *Caused by: java.lang.NoSuchMethodError:
> hudson.remoting.VirtualChannel.syncLocalIO()V
> at hudson.FilePath.copyTo(FilePath.java:1411)*

> at hudson.FilePath.copyTo(FilePath.java:1370)
> at
> hudson.plugins.logparser.LogParserStatusComputer.computeStatusMatches(LogParserStatusComputer.java:79)
> at
> hudson.plugins.logparser.LogParserStatusComputer.access$000(LogParserStatusComputer.java:23)
> at
> hudson.plugins.logparser.LogParserStatusComputer$1.call(LogParserStatusComputer.java:45)
> at
> hudson.plugins.logparser.LogParserStatusComputer$1.call(LogParserStatusComputer.java:40)
> at hudson.remoting.UserRequest.perform(UserRequest.java:104)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:270)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> 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:619)

--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/

[John Borghi]

Thanks Kohsuke, that did the trick! We were using a local (and old) copy of slave.jar in a custom launch script. Thanks for restoring order to the world, at least this portion of it!

[Kohsuke Kawaguchi]

On 05/11/2011 11:58 AM, John Borghi wrote:
> Thanks Kohsuke, that did the trick! We were using a local (and old)
> copy of slave.jar in a custom launch script. Thanks for restoring order
> to the world, at least this portion of it!

LOL.

I've been badly in need of good chuckles for the past several days.
Thanks for giving me one!