Nightlies failing due to java.lang.IllegalArgumentException: Unable to locate class file for class hudson.remoting.Launcher

303 views
Skip to first unread message

Tim Downey

unread,
Aug 10, 2011, 8:11:07 AM8/10/11
to jenkins...@googlegroups.com
Hi,

At least one night a week all of my nightlies on slave nodes are failing due to "java.lang.IllegalArgumentException: Unable to locate class file for class hudson.remoting.Launcher".  This seems to occur only on my nightly builds, but I may just not be looking hard enough at our continuous builds.  Our setup has about 20 builds that all kick off every night at around midnight in addition to normal source code polling builds for CI.  To make matters more confusing, the situation resolves itself.  For instance, last night I had about a dozen builds fail with this message.  I know from experience with the issue that if I wait, I probably will not see the issue again tonight.  It will come back in a few days instead.

I'm running Jenkins 1.424 on Windows 2008 for master and slaves (virtual machines).  Due to the nature of the issue, it only occurs on slaves, but doesn't always occur on the same slave.  Has anyone seen and solved this problem?

Here's the trace.  Thanks for any help.

Tim

------------------------------------------

Started by an SCM change

Building remotely on Srikanth

[C-tms-welcome] $ "C:\Program Files\TortoiseHg/hg" incoming --quiet --bundle hg.bundle --template "<changeset node='{node}' author='{author|xmlescape}' rev='{rev}' date='{date}'><msg>{desc|xmlescape}</msg><added>{file_adds|stringify|xmlescape}</added><deleted>{file_dels|stringify|xmlescape}</deleted><files>{files|stringify|xmlescape}</files><parents>{parents}</parents></changeset>\n" --rev default [C-tms-welcome] $ "C:\Program Files\TortoiseHg/hg" --debug log --rev . --template {node} Parsing POMs

ERROR: Processing failed due to a bug in the code. Please report this to jenkins...@googlegroups.com

java.lang.IllegalArgumentException: Unable to locate class file for class hudson.remoting.Launcher

                at hudson.remoting.Which.jarURL(Which.java:60)

                at hudson.remoting.Which.jarFile(Which.java:75)

                at hudson.maven.AbstractMavenProcessFactory$GetRemotingJar.call(AbstractMavenProcessFactory.java:313)

                at hudson.maven.AbstractMavenProcessFactory$GetRemotingJar.call(AbstractMavenProcessFactory.java:311)

                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 java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)

                at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)

                at java.util.concurrent.FutureTask.run(Unknown Source)

                at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

                at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

                at hudson.remoting.Engine$1$1.run(Engine.java:60)

                at java.lang.Thread.run(Unknown Source) project=hudson.maven.MavenModuleSet@4ce1e2b3[C-tms-welcome]

project.getModules()=[hudson.maven.MavenModule@61a0353d[C-tms-welcome/com.workscape.flex:Welcome][C-tms-welcome/com.workscape.flex:Welcome][relativePath:Welcome], hudson.maven.MavenModule@5d0769dd[C-tms-welcome/com.workscape.welcome:welcome-aggregate][C-tms-welcome/com.workscape.welcome:welcome-aggregate][relativePath:]]

project.getRootModule()=hudson.maven.MavenModule@5d0769dd[C-tms-welcome/com.workscape.welcome:welcome-aggregate][C-tms-welcome/com.workscape.welcome:welcome-aggregate][relativePath:]

FATAL: Unable to locate class file for class hudson.remoting.Launcher

java.lang.IllegalArgumentException: Unable to locate class file for class hudson.remoting.Launcher

                at hudson.remoting.Which.jarURL(Which.java:60)

                at hudson.remoting.Which.jarFile(Which.java:75)

                at hudson.maven.AbstractMavenProcessFactory$GetRemotingJar.call(AbstractMavenProcessFactory.java:313)

                at hudson.maven.AbstractMavenProcessFactory$GetRemotingJar.call(AbstractMavenProcessFactory.java:311)

                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 java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)

                at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)

                at java.util.concurrent.FutureTask.run(Unknown Source)

                at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

                at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

                at hudson.remoting.Engine$1$1.run(Engine.java:60)

                at java.lang.Thread.run(Unknown Source)

Martin B.

unread,
Aug 10, 2011, 8:30:50 AM8/10/11
to jenkins...@googlegroups.com
Hi Tim,

You wrote "This seems to occur only on my nightly builds" but the
logging you attached starts with "started by an SCM change". -> ?

- Martin

> jenkins...@googlegroups.com <mailto:jenkins...@googlegroups.com>


>
> java.lang.IllegalArgumentException: Unable to locate class file for
> class hudson.remoting.Launcher
>
> at hudson.remoting.Which.jarURL(Which.java:60)
>
> at hudson.remoting.Which.jarFile(Which.java:75)
>
> at
> hudson.maven.AbstractMavenProcessFactory$GetRemotingJar.call(AbstractMavenProcessFactory.java:313)
>
> at
> hudson.maven.AbstractMavenProcessFactory$GetRemotingJar.call(AbstractMavenProcessFactory.java:311)
>
> 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 java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
>
> at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
>
> at java.util.concurrent.FutureTask.run(Unknown Source)
>
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
>
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>
> at hudson.remoting.Engine$1$1.run(Engine.java:60)
>
> at java.lang.Thread.run(Unknown Source)
> project=hudson.maven.MavenModuleSet@4ce1e2b3[C-tms-welcome

> <mailto:project=hudson.maven.MavenModuleSet@4ce1e2b3[C-tms-welcome>]


>
> project.getModules()=[hudson.maven.MavenModule@61a0353d[C-tms-welcome/com.workscape.flex:Welcome][C-tms-welcome/com.workscape.flex:Welcome][relativePath:Welcome],
> hudson.maven.MavenModule@5d0769dd[C-tms-welcome/com.workscape.welcome:welcome-aggregate][C-tms-welcome/com.workscape.welcome:welcome-aggregate][relativePath

> <mailto:hudson.maven.MavenModule@5d0769dd[C-tms-welcome/com.workscape.welcome:welcome-aggregate%5d%5bC-tms-welcome/com.workscape.welcome:welcome-aggregate%5d%5brelativePath>:]]


>
> project.getRootModule()=hudson.maven.MavenModule@5d0769dd[C-tms-welcome/com.workscape.welcome:welcome-aggregate][C-tms-welcome/com.workscape.welcome:welcome-aggregate][relativePath

> <mailto:=hudson.maven.MavenModule@5d0769dd[C-tms-welcome/com.workscape.welcome:welcome-aggregate%5d%5bC-tms-welcome/com.workscape.welcome:welcome-aggregate%5d%5brelativePath>:]

Tim Downey

unread,
Aug 10, 2011, 8:49:46 AM8/10/11
to jenkins...@googlegroups.com
Hi Martin,

Interesting.  I hadn't noticed that.  Not sure if it is related, or if it is a separate issue.  Either way, I guess it raises a question.  How does everyone manage their nightlies?  All of my builds are normally used for continuous integration via source polling (Mercurial if it matters).  Additionally, I've got them set up to run scheduled at midnight.  These nightlies normally trigger Sonar to collect all of my build/code statistics.  Is this normal, or do most people use separate jobs for their scheduled builds?  I can do that, but I hate to duplicate the configuration.

I'm also not totally clear on how source polling works with slave nodes.  I'd assume that the master is reponsible for all polling to avoid ending up with each of the slaves finding changes separately at different times.  In this particular case, the SCM change that was detected was 7 days old and had definitely been built before (but not on the particular slave that was about to perform the build).

Even despite that confusion over what triggered the build, can anyone explain the issue?  It's as if the slave node has had its classpath get fouled up.  (fwiw, my slaves have been triggered by JNLP)

Tim

Steven M

unread,
Oct 24, 2013, 4:13:08 PM10/24/13
to jenkins...@googlegroups.com
Has anyone solved this issue? We are seeing the exact same issue. We are running with Jenkins version 1.525.
Reply all
Reply to author
Forward
0 new messages