Jenkins Build error java.lang.ClassNotFoundExcepti

Question

I am trying to integrate jenkins with svn. I have configured maven_home, java_home (java 1.5 update 22). I am using jenkins version 1.459 . One of my colleague successfully configured jenkins with the svn.But as now we are using a different branch, I wanted to add a new job so that it checkout from the new branch and continuous integrate the project. Jenkins is running in a remote linux machine and I use vpn to connect to the server and set up the things.What am I missing.

Modules changed, recalculating dependency graph
[workspace] $ /usr/lib/jvm/jdk1.5.0_22/bin/java -cp /home/vimukthi/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-agent-1.2.jar:/home/vimukthi/.jenkins/tools/Maven_3.0.3/boot/plexus-classworlds-2.4.jar org.jvnet.hudson.maven3.agent.Maven3Main /home/vimukthi/.jenkins/tools/Maven_3.0.3 /tmp/Jetty_0_0_0_0_2080_jenkins.war__jenkins__.wq5y0j/webinf/WEB-INF/lib/remoting-2.13.jar /home/vimukthi/.jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-1.2.jar 45339

Exception in thread "main" java.lang.ClassNotFoundException: hudson.remoting.Launcher
    at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
    at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
    at org.jvnet.hudson.maven3.agent.Maven3Main.main(Maven3Main.java:130)
    at org.jvnet.hudson.maven3.agent.Maven3Main.main(Maven3Main.java:63)
ERROR: Failed to parse POMs
java.net.SocketException: Connection reset
    at java.net.SocketInputStream.read(SocketInputStream.java:168)
    at java.io.FilterInputStream.read(FilterInputStream.java:116)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
    at hudson.remoting.ClassicCommandTransport.create(ClassicCommandTransport.java:98)
    at hudson.remoting.Channel.<init>(Channel.java:373)
    at hudson.remoting.Channel.<init>(Channel.java:369)
    at hudson.remoting.Channel.<init>(Channel.java:330)
    at hudson.remoting.Channel.<init>(Channel.java:326)
    at hudson.remoting.Channel.<init>(Channel.java:322)
    at hudson.slaves.Channels$1.<init>(Channels.java:71)
    at hudson.slaves.Channels.forProcess(Channels.java:71)
    at hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:237)
    at hudson.maven.ProcessCache.get(ProcessCache.java:231)
    at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:706)
    at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475)
    at hudson.model.Run.run(Run.java:1413)
    at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:479)
    at hudson.model.ResourceController.execute(ResourceController.java:88)
    at hudson.model.Executor.run(Executor.java:238)
Sending e-mails to: [e-mail]
Finished: FAILURE

Answer 1

This error can be reproduced by corrupting the libraries in the slave's build root directory. In that case, reconnecting the slave fixes the situation, because by reconnecting a slave, jenkins copies over all the necessary libraries etc..

TO see this in action, watch the jenkins console when you reconnect, you will see something like this:

Slave.jar version: 2.28

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

So, whats happening, is all the libraries are resync'd by jenkins. This can be chalked up to a bug (imho) in jenkins... Ideally the slaves should be robust to these kind of failures.

Answer 2

I have seen this issue couple of times in our test environment and providing slave.jar solved this issue.

Unfortunately there was a job which only moved maven-agent* and not slave.jar whenever environment was rebuilt, and we used to face this issue repeatedly.

Copying slave.jar fixed this issue.

Answer 3

Looks like I managed to solve the problem. Disconnecting and reconnecting the slave solves it only temporarily. But what I did is, I changed the java that master and slaves run with. Now my slaves and master run with exactly the same version of java (6u41 32bit) and it's about 3 weeks we don't face this kind of problems.