Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-31718

JNLP slaves can fail to correctly negotiate a transport


      The changes in PR 41 introduced a regression whereby the read-ahead buffered input stream gets thrown away after the protocol has been detected but before the protocol negotiation starts.

      The result of this is that depending on random timing factors, the capability and mode information that has been sent to the remote side may get lost and one side will infer a capability of 0 while the other side believes the agreed capability to be more.

      When the remote side is assuming chunking, the connection will typically fail immediately with an error such as:

      INFO: Protocol failed to establish channel
      java.io.StreamCorruptedException: invalid stream header: 0A6CACED
          at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:806)
          at java.io.ObjectInputStream.<init>(ObjectInputStream.java:299)
          at hudson.remoting.ObjectInputStreamEx.<init>(ObjectInputStreamEx.java:48)
          at hudson.remoting.ChannelBuilder.makeTransport(ChannelBuilder.java:430)
          at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:389)
          at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:310)
          at org.jenkinsci.remoting.engine.JnlpProtocol2.buildChannel(JnlpProtocol2.java:93)
          at org.jenkinsci.remoting.engine.JnlpProtocol.establishChannel(JnlpProtocol.java:79)
          at hudson.remoting.Engine.run(Engine.java:245)

      But if the remote side is not assuming chunking then more subtle remoting issues could arise (e.g. if the remote slave is running an older pre-chunking slave.jar and connecting to a newer Jenkins... not that you should be doing that, but some people may... this reason is why I argue the issue is "Critical")

            stephenconnolly Stephen Connolly
            stephenconnolly Stephen Connolly
            0 Vote for this issue
            5 Start watching this issue