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

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

Related Issues

Explanation

In most cases, java.io.StreamCorruptedException in the context of remoting is caused by incompatibility issues between master 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 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 master 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

Have more questions?

0 Comments

Please sign in to leave a comment.