Issue
-
When launching an agent using WebSocket transport, the agent cannot connect and the launch logs show:
Aug 06, 2020 7:07:52 AM hudson.remoting.AbstractByteArrayCommandTransport$1 handle WARNING: Failed to construct Command in channel dse-team-apac-jenkins-61409-rm3bf java.io.StreamCorruptedException: invalid stream header: 0AD8ACED at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:900) at java.io.ObjectInputStream.<init>(ObjectInputStream.java:358) at hudson.remoting.ObjectInputStreamEx.<init>(ObjectInputStreamEx.java:49) at hudson.remoting.Command.readFrom(Command.java:142) at hudson.remoting.Command.readFrom(Command.java:128) at hudson.remoting.AbstractByteArrayCommandTransport$1.handle(AbstractByteArrayCommandTransport.java:64) [...]
Environment
-
CloudBees CI (CloudBees Core) on traditional platforms - Client controller
-
CloudBees CI (CloudBees Core) on traditional platforms - Operations Center
-
CloudBees Jenkins Enterprise - Managed controller
-
CloudBees Jenkins Enterprise - Operations center
Related Issues
-
JENKINS-61409 Websocket connections crash if message size is greater than 64Kb
Explanation
In most cases, java.io.StreamCorruptedException
in the context of remoting is caused by incompatibility issues between controller remoting and agents remoting versions. This is not exception.
In that particular scenario with hudson.remoting.AbstractByteArrayCommandTransport
the problem is most likely due the fix for JENKINS-61409. This fix changed the WebSocket transport implementation to use ByteBuffer
instead of ByteArray
making earlier version of remoting incompatible.
-
The fix is released in Remoting 4.2.1
-
The fix is released in Jenkins Core 2.222.4
The Kubernetes plugin
A specific scenario is the Kubernetes plugin. The plugin uses a hard coded default image of remoting. The version 1.26.0 of the Kubernetes plugin uses Remoting 4.3 by default and requires Jenkins 2.222.4. However, nothing prevent a Jenkins instance running 2.222.4+ from using an older version of the plugin, in which case the issue arises.
Note: Version 2.222.4.3 and 2.235.1.2 of CloudBees CI (non modern) allow Kubernetes plugin at versions earlier than 1.26.0 under the CloudBees Assurance Program and are subjected to this problem.*
Resolution
Dedicated Inbound Agents
To solve the problem fix the incompatibility issue:
-
For Jenkins 2.222.4 or later, use version 4.2.1 or later of remoting
-
For earlier version of Jenkins, use version 4.2 or earlier of remoting
In general, download the $JENKINS_URL/jnlpJars/agent.jar
from the controller to get the compatible version.
Kubernetes Plugin
If using CloudBees CI 2.222.4.1 or 2.235.1.2 with the CloudBees Assurance program:
-
the recommended solution is to upgrade to 2.235.2.3 or later to fix the problem
Otherwise for jenkins TLS, to solve the problem fix the incompatibility issue:
-
If using Jenkins version 2.222.4 or later, use version 1.26.0 or later of the Kubernetes plugin
Workaround
A workaround until a resolution path can be taken is to change the default image for the jnlp
container, see Change the default JNLP image for kubernetes agents provisioning. Follow the same rules:
-
For Jenkins 2.222.4 or later, use
jenkins/inbound-agent:4.3-4
-
For earlier version of Jenkins, use
jenkins/jnlp-slave:4.0.1-1