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

CLI, Agent -websockets DeploymentException: Handshake response not received on jdk-11

    Details

    • Similar Issues:

      Description

      Testing CLI, agent connections with the new '-websocket' functionality added by
      JEP-222.

       

      Jetty access log shows:

      172.18.0.3 - - [25/Feb/2020:01:48:06 +0000] "GET /cli/ws HTTP/1.1" 101 0 "-" "-" 
      

      CLI output:

      javax.websocket.DeploymentException: Handshake response not received.
      	at org.glassfish.tyrus.client.ClientManager$3$1.run(ClientManager.java:694)
      	at org.glassfish.tyrus.client.ClientManager$3.run(ClientManager.java:712)
      ...
      	at org.glassfish.tyrus.client.ClientManager$SameThreadExecutorService.execute(ClientManager.java:866)
      	at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
      	at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:511)
      	at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:355)
      	at hudson.cli.CLI.webSocketConnection(CLI.java:323)
      	at hudson.cli.CLI._main(CLI.java:301)
      	at hudson.cli.CLI.main(CLI.java:95)
      

      When I attach a debugger to the Jenkins server it seems to get stuck here:
      https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/cli/CLIAction.java#L255

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            I should add that the motivating use case for JEP-222 is Jenkins running behind a reverse proxy (such as Kubernetes ingress), in which case TLS is typically terminated at the proxy. If the problem involves some sort of incompatibility between the TLS implementation in Tyrus (or whatever library it is using for that) on the client side vs. the TLS implementation in Jetty running on Java 11 on the server side, then it would presumably not affect this environment.

            Show
            jglick Jesse Glick added a comment - I should add that the motivating use case for JEP-222 is Jenkins running behind a reverse proxy (such as Kubernetes ingress), in which case TLS is typically terminated at the proxy. If the problem involves some sort of incompatibility between the TLS implementation in Tyrus (or whatever library it is using for that) on the client side vs. the TLS implementation in Jetty running on Java 11 on the server side, then it would presumably not affect this environment.
            Hide
            jpschewe jpschewe added a comment -

            I've tried setting up a node with the websocket option and got the handshake error specified here. Both the node and the Jenkins host are using openJDK 11. The Jenkins host is behind Apache using mod_proxy. Apache is terminating the TLS connection. Switching off the websocket option and opening the JNLP port allows my node to connect to the host.

             

            Show
            jpschewe jpschewe added a comment - I've tried setting up a node with the websocket option and got the handshake error specified here. Both the node and the Jenkins host are using openJDK 11. The Jenkins host is behind Apache using mod_proxy. Apache is terminating the TLS connection. Switching off the websocket option and opening the JNLP port allows my node to connect to the host.  
            Hide
            build_admiral Fred Vogt added a comment -

            jpschewe - I haven't isolated the smallest reproducible case.

            You encountering this issue is at least another data point.

            Show
            build_admiral Fred Vogt added a comment - jpschewe - I haven't isolated the smallest reproducible case. https://github.com/fred-vogt/jenkins-websockets-tester - [no authentication] + [TLS] - no hang https://github.com/cicdenv/cicdenv/tree/master/jenkins - [Github OAuth] + [TLS] - hangs You encountering this issue is at least another data point.
            Hide
            jpschewe jpschewe added a comment -

            I'm starting my node on Linux with the following command inside a shell script. The shell script is launched as an unprivileged user from systemd.

            nohup java -jar agent.jar -jnlpUrl https://${jenkins_host}/computer/${jenkins_node_name}/slave-agent.jnlp -secret ${jenkins_node_secret} -workDir "${HOME}" > "${HOME}"/jenkins-node.log 2>&1 
            Show
            jpschewe jpschewe added a comment - I'm starting my node on Linux with the following command inside a shell script. The shell script is launched as an unprivileged user from systemd. nohup java -jar agent.jar -jnlpUrl https: //${jenkins_host}/computer/${jenkins_node_name}/slave-agent.jnlp -secret ${jenkins_node_secret} -workDir "${HOME}" > "${HOME}" /jenkins-node.log 2>&1
            Hide
            jpschewe jpschewe added a comment -

            I have the same error when I enable the websocket option for a node that is running on Windows 10 with Oracle Java 1.8.

            Show
            jpschewe jpschewe added a comment - I have the same error when I enable the websocket option for a node that is running on Windows 10 with Oracle Java 1.8.

              People

              • Assignee:
                Unassigned
                Reporter:
                build_admiral Fred Vogt
              • Votes:
                2 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated: