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
• CloudBees Jenkins Platform - Client controller
• CloudBees Jenkins Platform - Operations Center
• Jenkins LTS
• Jenkins Remoting
• WebSocket
• Kubernetes plugin

Related Issues

• JENKINS-61409 Websocket connections crash if message size is greater than 64Kb
  • jenkinsci/jenkins #4596
  • jenkinsci/remoting #373
  • jenkinsci/kubernetes #749

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