Observed the following stacktrace when running a controller using JDK17 bytecode level, and having an agent template still configured with a JDK11. The agent initially connects fine, however as soon as it attempts to do remote classloading, it fails.
As it occurs while setting up the hudson.remoting.Channel itself, the listener that is registered during initialization is never called, and the exception handling block should instead close the underlying resources.
WARNING c.g.j.p.c.ComputeEngineCloud#log: Error: java.lang.UnsupportedClassVersionError: hudson/slaves/SlaveComputer$SlaveVersion has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1017)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:878)
at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:470)
Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to gce-cloud-gauntlet3-gaia-jdk11-t4dx04
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1923)
at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:384)
at hudson.remoting.Channel.call(Channel.java:1112)
at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:663)
at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:441)
at PluginClassLoader for google-compute-engine//com.google.jenkins.plugins.computeengine.ComputeEngineComputerLauncher.launch(ComputeEngineComputerLauncher.java:303)
at PluginClassLoader for google-compute-engine//com.google.jenkins.plugins.computeengine.ComputeEngineComputerLauncher.launch(ComputeEngineComputerLauncher.java:214)
at hudson.slaves.SlaveComputer.lambda$_connect$0(SlaveComputer.java:297)
at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
at jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:80)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:840)
Caused: java.lang.UnsupportedClassVersionError: Failed to load hudson.slaves.SlaveComputer$SlaveVersion
at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:472)
at hudson.remoting.RemoteClassLoader.loadRemoteClass(RemoteClassLoader.java:301)
at hudson.remoting.RemoteClassLoader.loadWithMultiClassLoader(RemoteClassLoader.java:277)
at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:236)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:589)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:398)
at hudson.remoting.MultiClassLoaderSerializer$Input.resolveClass(MultiClassLoaderSerializer.java:133)
at java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2003)
at java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1870)
at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2201)
at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1687)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:489)
at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:447)
at hudson.remoting.UserRequest.deserialize(UserRequest.java:312)
at hudson.remoting.UserRequest.perform(UserRequest.java:196)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:391)
at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:81)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused: java.io.IOException: Remote call on gce-cloud-gauntlet3-gaia-jdk11-t4dx04 failed
at hudson.remoting.Channel.call(Channel.java:1116)
at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:663)
at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:441)
at PluginClassLoader for google-compute-engine//com.google.jenkins.plugins.computeengine.ComputeEngineComputerLauncher.launch(ComputeEngineComputerLauncher.java:303)
at PluginClassLoader for google-compute-engine//com.google.jenkins.plugins.computeengine.ComputeEngineComputerLauncher.launch(ComputeEngineComputerLauncher.java:214)
at hudson.slaves.SlaveComputer.lambda$_connect$0(SlaveComputer.java:297)
at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
at jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:80)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:840)
Testing done
Submitter checklist
[x] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
[x] Ensure that the pull request title represents the desired changelog entry
[x] Please describe what you did
[ ] Link to relevant issues in GitHub or Jira
[ ] Link to relevant pull requests, esp. upstream and downstream changes
[ ] Ensure you have provided tests - that demonstrates feature works or fixes the issue
Observed the following stacktrace when running a controller using JDK17 bytecode level, and having an agent template still configured with a JDK11. The agent initially connects fine, however as soon as it attempts to do remote classloading, it fails.
As it occurs while setting up the
hudson.remoting.Channelitself, the listener that is registered during initialization is never called, and the exception handling block should instead close the underlying resources.Testing done
Submitter checklist