WebSocket Inbound Agent launch fails with java.io.StreamCorruptedException over AbstractByteArrayCommandTransport

Article ID:360048628631
2 minute readKnowledge base


  • 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)


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 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 and 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.*


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 or with the CloudBees Assurance program:

  • the recommended solution is to upgrade to 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


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