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

JNLP agent timeout due to to strict verification check by DefaultJnlpSlaveReceiver

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: openstack-cloud-plugin
    • Labels:
      None
    • Environment:
    • Similar Issues:

      Description

      Hello,

      I've ran into an issue when launching a windows JNLP agent via the OpenStack Cloud Plugin.

      The OpenStack Plugin was correctly spinning up my VM, but the slave failed to connect to my jenkins master.

      To troubleshoot, I downloaded the slave.jar and launched the JNLP slave manually using this command from the slave node:

      $ java -jar slave.jar -jnlpUrl http://yourserver:port/computer/slave-name/slave-agent.jnlp
      

      I received the following error:

      INFO: Trying protocol: JNLP-connect
      Jan 23, 2017 12:03:59 PM hudson.remoting.jnlp.Main$CuiListener status
      INFO: Protocol JNLP-connect encountered an unexpected exception
      java.util.concurrent.ExecutionException: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Server didn't
      accept the handshake:
      at java.util.concurrent.FutureTask.report(Unknown Source)
      at java.util.concurrent.FutureTask.get(Unknown Source)
      at hudson.remoting.Engine.innerRun(Engine.java:385)
      at hudson.remoting.Engine.run(Engine.java:287)
      Caused by: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Server didn't accept the handshake:
      at org.jenkinsci.remoting.engine.JnlpProtocol1Handler.sendHandshake(JnlpProtocol1Handler.java:121)
      at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$2.call(LegacyJnlpProtocolHandler.java:162)
      at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$2.call(LegacyJnlpProtocolHandler.java:158)
      at java.util.concurrent.FutureTask.run(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      at hudson.remoting.Engine$1$1.run(Engine.java:94)
      at java.lang.Thread.run(Unknown Source)

      Jan 23, 2017 12:03:59 PM hudson.remoting.jnlp.Main$CuiListener error
      SEVERE: The server rejected the connection: None of the protocols were accepted
      java.lang.Exception: The server rejected the connection: None of the protocols were accepted
      at hudson.remoting.Engine.onConnectionRejected(Engine.java:484)
      at hudson.remoting.Engine.innerRun(Engine.java:448)
      at hudson.remoting.Engine.run(Engine.java:287)

      When investigating the logs on the Jenkins master, I noticed this:

      INFO: Accepted connection #5 from /10.0.0.24:50749
      Jan 21, 2017 1:18:33 AM jenkins.slaves.DefaultJnlpSlaveReceiver afterProperties
      WARNING: Rejecting connection to dynamic-windows-autogen-1835 from /10.0.0.24:50749 as a JNLP agent as the launcher class jenkins.plugins.openstack.compute.JCloudsLauncher does not extend JNLPLauncher or does not implement DelegatingComputerLauncher with a delegation chain leading to a JNLPLauncher. Set system property jenkins.slaves.DefaultJnlpSlaveReceiver.disableStrictVerification=true to allowconnections until the plugin has been fixed.

      Following the error message, I ran the following command from my jenkin master's groovy script console (http://master/script)

      jenkins.slaves.DefaultJnlpSlaveReceiver.disableStrictVerification=true
      

      Then I re-launched the JNLP agent using the same command and the connection was established. Likewise, after disabling strict verification, I was able to provision the node via the OpenStack Cloud plugin.

      Disabling strict verification on the DefaultJnlpSlaveReceiver appears to work, is this the correct approach?

      As an aside, creating a permanent node via the JNLP WebStart works and does not require disabling strict verification.

      Thank you for all your hard work.

      Regards,
      Ryan

        Attachments

          Issue Links

            Activity

            thornto4 Ryan Thornton created issue -
            thornto4 Ryan Thornton made changes -
            Field Original Value New Value
            Description Hello,

            I've ran into an issue when launching a windows JNLP agent via the OpenStack Plugin Cloud.

            The OpenStack Plugin was correctly spinning up my VM, but the slave failed to connect to my jenkins master.

            To troubleshoot, I downloaded the slave.jar and launched the JNLP slave manually using this command from the slave node:

            {code:java}
            $ java -jar slave.jar -jnlpUrl http://yourserver:port/computer/slave-name/slave-agent.jnlp
            {code}

            I received the following error:

            {quote}
            INFO: Trying protocol: JNLP-connect
            Jan 23, 2017 12:03:59 PM hudson.remoting.jnlp.Main$CuiListener status
            INFO: Protocol JNLP-connect encountered an unexpected exception
            java.util.concurrent.ExecutionException: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Server didn't
            accept the handshake:
                    at java.util.concurrent.FutureTask.report(Unknown Source)
                    at java.util.concurrent.FutureTask.get(Unknown Source)
                    at hudson.remoting.Engine.innerRun(Engine.java:385)
                    at hudson.remoting.Engine.run(Engine.java:287)
            Caused by: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Server didn't accept the handshake:
                    at org.jenkinsci.remoting.engine.JnlpProtocol1Handler.sendHandshake(JnlpProtocol1Handler.java:121)
                    at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$2.call(LegacyJnlpProtocolHandler.java:162)
                    at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$2.call(LegacyJnlpProtocolHandler.java:158)
                    at java.util.concurrent.FutureTask.run(Unknown Source)
                    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
                    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
                    at hudson.remoting.Engine$1$1.run(Engine.java:94)
                    at java.lang.Thread.run(Unknown Source)

            Jan 23, 2017 12:03:59 PM hudson.remoting.jnlp.Main$CuiListener error
            SEVERE: The server rejected the connection: None of the protocols were accepted
            java.lang.Exception: The server rejected the connection: None of the protocols were accepted
                    at hudson.remoting.Engine.onConnectionRejected(Engine.java:484)
                    at hudson.remoting.Engine.innerRun(Engine.java:448)
                    at hudson.remoting.Engine.run(Engine.java:287)
            {quote}

            When investigating the logs on the Jenkins master, I noticed this:

            {quote}
            INFO: Accepted connection #5 from /10.0.0.24:50749
            Jan 21, 2017 1:18:33 AM jenkins.slaves.DefaultJnlpSlaveReceiver afterProperties
            WARNING: Rejecting connection to dynamic-windows-autogen-1835 from /10.0.0.24:50749 as a JNLP agent as the launcher class jenkins.plugins.openstack.compute.JCloudsLauncher does not extend JNLPLauncher or does not implement DelegatingComputerLauncher with a delegation chain leading to a JNLPLauncher. Set system property jenkins.slaves.DefaultJnlpSlaveReceiver.disableStrictVerification=true to allowconnections until the plugin has been fixed.
            {quote}

            Following the error message, I ran the following command from my jenkin master's groovy script console (http://master/script)

            {code:java}
            jenkins.slaves.DefaultJnlpSlaveReceiver.disableStrictVerification=true
            {code}

            Then I re-launched the JNLP agent using the same command and the connection was established. Likewise, after disabling strict verification, I was likewise able to provision the node via the OpenStack Cloud plugin.

            Disabling strict verification on the DefaultJnlpSlaveReceiver appears to work, is this the correct approach?

            As an aside, creating a permanent node via the JNLP WebStart works and does not require disabling strict verification.

            Thank you for all your hard work.

            Regards,
            Ryan
            Hello,

            I've ran into an issue when launching a windows JNLP agent via the OpenStack Plugin Cloud.

            The OpenStack Plugin was correctly spinning up my VM, but the slave failed to connect to my jenkins master.

            To troubleshoot, I downloaded the slave.jar and launched the JNLP slave manually using this command from the slave node:

            {code:java}
            $ java -jar slave.jar -jnlpUrl http://yourserver:port/computer/slave-name/slave-agent.jnlp
            {code}

            I received the following error:

            {quote}
            INFO: Trying protocol: JNLP-connect
            Jan 23, 2017 12:03:59 PM hudson.remoting.jnlp.Main$CuiListener status
            INFO: Protocol JNLP-connect encountered an unexpected exception
            java.util.concurrent.ExecutionException: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Server didn't
            accept the handshake:
                    at java.util.concurrent.FutureTask.report(Unknown Source)
                    at java.util.concurrent.FutureTask.get(Unknown Source)
                    at hudson.remoting.Engine.innerRun(Engine.java:385)
                    at hudson.remoting.Engine.run(Engine.java:287)
            Caused by: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Server didn't accept the handshake:
                    at org.jenkinsci.remoting.engine.JnlpProtocol1Handler.sendHandshake(JnlpProtocol1Handler.java:121)
                    at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$2.call(LegacyJnlpProtocolHandler.java:162)
                    at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$2.call(LegacyJnlpProtocolHandler.java:158)
                    at java.util.concurrent.FutureTask.run(Unknown Source)
                    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
                    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
                    at hudson.remoting.Engine$1$1.run(Engine.java:94)
                    at java.lang.Thread.run(Unknown Source)

            Jan 23, 2017 12:03:59 PM hudson.remoting.jnlp.Main$CuiListener error
            SEVERE: The server rejected the connection: None of the protocols were accepted
            java.lang.Exception: The server rejected the connection: None of the protocols were accepted
                    at hudson.remoting.Engine.onConnectionRejected(Engine.java:484)
                    at hudson.remoting.Engine.innerRun(Engine.java:448)
                    at hudson.remoting.Engine.run(Engine.java:287)
            {quote}

            When investigating the logs on the Jenkins master, I noticed this:

            {quote}
            INFO: Accepted connection #5 from /10.0.0.24:50749
            Jan 21, 2017 1:18:33 AM jenkins.slaves.DefaultJnlpSlaveReceiver afterProperties
            WARNING: Rejecting connection to dynamic-windows-autogen-1835 from /10.0.0.24:50749 as a JNLP agent as the launcher class jenkins.plugins.openstack.compute.JCloudsLauncher does not extend JNLPLauncher or does not implement DelegatingComputerLauncher with a delegation chain leading to a JNLPLauncher. Set system property jenkins.slaves.DefaultJnlpSlaveReceiver.disableStrictVerification=true to allowconnections until the plugin has been fixed.
            {quote}

            Following the error message, I ran the following command from my jenkin master's groovy script console (http://master/script)

            {code:java}
            jenkins.slaves.DefaultJnlpSlaveReceiver.disableStrictVerification=true
            {code}

            Then I re-launched the JNLP agent using the same command and the connection was established. Likewise, after disabling strict verification, I was able to provision the node via the OpenStack Cloud plugin.

            Disabling strict verification on the DefaultJnlpSlaveReceiver appears to work, is this the correct approach?

            As an aside, creating a permanent node via the JNLP WebStart works and does not require disabling strict verification.

            Thank you for all your hard work.

            Regards,
            Ryan
            thornto4 Ryan Thornton made changes -
            Description Hello,

            I've ran into an issue when launching a windows JNLP agent via the OpenStack Plugin Cloud.

            The OpenStack Plugin was correctly spinning up my VM, but the slave failed to connect to my jenkins master.

            To troubleshoot, I downloaded the slave.jar and launched the JNLP slave manually using this command from the slave node:

            {code:java}
            $ java -jar slave.jar -jnlpUrl http://yourserver:port/computer/slave-name/slave-agent.jnlp
            {code}

            I received the following error:

            {quote}
            INFO: Trying protocol: JNLP-connect
            Jan 23, 2017 12:03:59 PM hudson.remoting.jnlp.Main$CuiListener status
            INFO: Protocol JNLP-connect encountered an unexpected exception
            java.util.concurrent.ExecutionException: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Server didn't
            accept the handshake:
                    at java.util.concurrent.FutureTask.report(Unknown Source)
                    at java.util.concurrent.FutureTask.get(Unknown Source)
                    at hudson.remoting.Engine.innerRun(Engine.java:385)
                    at hudson.remoting.Engine.run(Engine.java:287)
            Caused by: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Server didn't accept the handshake:
                    at org.jenkinsci.remoting.engine.JnlpProtocol1Handler.sendHandshake(JnlpProtocol1Handler.java:121)
                    at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$2.call(LegacyJnlpProtocolHandler.java:162)
                    at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$2.call(LegacyJnlpProtocolHandler.java:158)
                    at java.util.concurrent.FutureTask.run(Unknown Source)
                    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
                    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
                    at hudson.remoting.Engine$1$1.run(Engine.java:94)
                    at java.lang.Thread.run(Unknown Source)

            Jan 23, 2017 12:03:59 PM hudson.remoting.jnlp.Main$CuiListener error
            SEVERE: The server rejected the connection: None of the protocols were accepted
            java.lang.Exception: The server rejected the connection: None of the protocols were accepted
                    at hudson.remoting.Engine.onConnectionRejected(Engine.java:484)
                    at hudson.remoting.Engine.innerRun(Engine.java:448)
                    at hudson.remoting.Engine.run(Engine.java:287)
            {quote}

            When investigating the logs on the Jenkins master, I noticed this:

            {quote}
            INFO: Accepted connection #5 from /10.0.0.24:50749
            Jan 21, 2017 1:18:33 AM jenkins.slaves.DefaultJnlpSlaveReceiver afterProperties
            WARNING: Rejecting connection to dynamic-windows-autogen-1835 from /10.0.0.24:50749 as a JNLP agent as the launcher class jenkins.plugins.openstack.compute.JCloudsLauncher does not extend JNLPLauncher or does not implement DelegatingComputerLauncher with a delegation chain leading to a JNLPLauncher. Set system property jenkins.slaves.DefaultJnlpSlaveReceiver.disableStrictVerification=true to allowconnections until the plugin has been fixed.
            {quote}

            Following the error message, I ran the following command from my jenkin master's groovy script console (http://master/script)

            {code:java}
            jenkins.slaves.DefaultJnlpSlaveReceiver.disableStrictVerification=true
            {code}

            Then I re-launched the JNLP agent using the same command and the connection was established. Likewise, after disabling strict verification, I was able to provision the node via the OpenStack Cloud plugin.

            Disabling strict verification on the DefaultJnlpSlaveReceiver appears to work, is this the correct approach?

            As an aside, creating a permanent node via the JNLP WebStart works and does not require disabling strict verification.

            Thank you for all your hard work.

            Regards,
            Ryan
            Hello,

            I've ran into an issue when launching a windows JNLP agent via the OpenStack Cloud Plugin.

            The OpenStack Plugin was correctly spinning up my VM, but the slave failed to connect to my jenkins master.

            To troubleshoot, I downloaded the slave.jar and launched the JNLP slave manually using this command from the slave node:

            {code:java}
            $ java -jar slave.jar -jnlpUrl http://yourserver:port/computer/slave-name/slave-agent.jnlp
            {code}

            I received the following error:

            {quote}
            INFO: Trying protocol: JNLP-connect
            Jan 23, 2017 12:03:59 PM hudson.remoting.jnlp.Main$CuiListener status
            INFO: Protocol JNLP-connect encountered an unexpected exception
            java.util.concurrent.ExecutionException: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Server didn't
            accept the handshake:
                    at java.util.concurrent.FutureTask.report(Unknown Source)
                    at java.util.concurrent.FutureTask.get(Unknown Source)
                    at hudson.remoting.Engine.innerRun(Engine.java:385)
                    at hudson.remoting.Engine.run(Engine.java:287)
            Caused by: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Server didn't accept the handshake:
                    at org.jenkinsci.remoting.engine.JnlpProtocol1Handler.sendHandshake(JnlpProtocol1Handler.java:121)
                    at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$2.call(LegacyJnlpProtocolHandler.java:162)
                    at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$2.call(LegacyJnlpProtocolHandler.java:158)
                    at java.util.concurrent.FutureTask.run(Unknown Source)
                    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
                    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
                    at hudson.remoting.Engine$1$1.run(Engine.java:94)
                    at java.lang.Thread.run(Unknown Source)

            Jan 23, 2017 12:03:59 PM hudson.remoting.jnlp.Main$CuiListener error
            SEVERE: The server rejected the connection: None of the protocols were accepted
            java.lang.Exception: The server rejected the connection: None of the protocols were accepted
                    at hudson.remoting.Engine.onConnectionRejected(Engine.java:484)
                    at hudson.remoting.Engine.innerRun(Engine.java:448)
                    at hudson.remoting.Engine.run(Engine.java:287)
            {quote}

            When investigating the logs on the Jenkins master, I noticed this:

            {quote}
            INFO: Accepted connection #5 from /10.0.0.24:50749
            Jan 21, 2017 1:18:33 AM jenkins.slaves.DefaultJnlpSlaveReceiver afterProperties
            WARNING: Rejecting connection to dynamic-windows-autogen-1835 from /10.0.0.24:50749 as a JNLP agent as the launcher class jenkins.plugins.openstack.compute.JCloudsLauncher does not extend JNLPLauncher or does not implement DelegatingComputerLauncher with a delegation chain leading to a JNLPLauncher. Set system property jenkins.slaves.DefaultJnlpSlaveReceiver.disableStrictVerification=true to allowconnections until the plugin has been fixed.
            {quote}

            Following the error message, I ran the following command from my jenkin master's groovy script console (http://master/script)

            {code:java}
            jenkins.slaves.DefaultJnlpSlaveReceiver.disableStrictVerification=true
            {code}

            Then I re-launched the JNLP agent using the same command and the connection was established. Likewise, after disabling strict verification, I was able to provision the node via the OpenStack Cloud plugin.

            Disabling strict verification on the DefaultJnlpSlaveReceiver appears to work, is this the correct approach?

            As an aside, creating a permanent node via the JNLP WebStart works and does not require disabling strict verification.

            Thank you for all your hard work.

            Regards,
            Ryan
            thornto4 Ryan Thornton made changes -
            Link This issue duplicates JENKINS-39232 [ JENKINS-39232 ]
            thornto4 Ryan Thornton made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            kslice Kevin McHale made changes -
            Description Hello,

            I've ran into an issue when launching a windows JNLP agent via the OpenStack Cloud Plugin.

            The OpenStack Plugin was correctly spinning up my VM, but the slave failed to connect to my jenkins master.

            To troubleshoot, I downloaded the slave.jar and launched the JNLP slave manually using this command from the slave node:

            {code:java}
            $ java -jar slave.jar -jnlpUrl http://yourserver:port/computer/slave-name/slave-agent.jnlp
            {code}

            I received the following error:

            {quote}
            INFO: Trying protocol: JNLP-connect
            Jan 23, 2017 12:03:59 PM hudson.remoting.jnlp.Main$CuiListener status
            INFO: Protocol JNLP-connect encountered an unexpected exception
            java.util.concurrent.ExecutionException: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Server didn't
            accept the handshake:
                    at java.util.concurrent.FutureTask.report(Unknown Source)
                    at java.util.concurrent.FutureTask.get(Unknown Source)
                    at hudson.remoting.Engine.innerRun(Engine.java:385)
                    at hudson.remoting.Engine.run(Engine.java:287)
            Caused by: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Server didn't accept the handshake:
                    at org.jenkinsci.remoting.engine.JnlpProtocol1Handler.sendHandshake(JnlpProtocol1Handler.java:121)
                    at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$2.call(LegacyJnlpProtocolHandler.java:162)
                    at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$2.call(LegacyJnlpProtocolHandler.java:158)
                    at java.util.concurrent.FutureTask.run(Unknown Source)
                    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
                    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
                    at hudson.remoting.Engine$1$1.run(Engine.java:94)
                    at java.lang.Thread.run(Unknown Source)

            Jan 23, 2017 12:03:59 PM hudson.remoting.jnlp.Main$CuiListener error
            SEVERE: The server rejected the connection: None of the protocols were accepted
            java.lang.Exception: The server rejected the connection: None of the protocols were accepted
                    at hudson.remoting.Engine.onConnectionRejected(Engine.java:484)
                    at hudson.remoting.Engine.innerRun(Engine.java:448)
                    at hudson.remoting.Engine.run(Engine.java:287)
            {quote}

            When investigating the logs on the Jenkins master, I noticed this:

            {quote}
            INFO: Accepted connection #5 from /10.0.0.24:50749
            Jan 21, 2017 1:18:33 AM jenkins.slaves.DefaultJnlpSlaveReceiver afterProperties
            WARNING: Rejecting connection to dynamic-windows-autogen-1835 from /10.0.0.24:50749 as a JNLP agent as the launcher class jenkins.plugins.openstack.compute.JCloudsLauncher does not extend JNLPLauncher or does not implement DelegatingComputerLauncher with a delegation chain leading to a JNLPLauncher. Set system property jenkins.slaves.DefaultJnlpSlaveReceiver.disableStrictVerification=true to allowconnections until the plugin has been fixed.
            {quote}

            Following the error message, I ran the following command from my jenkin master's groovy script console (http://master/script)

            {code:java}
            jenkins.slaves.DefaultJnlpSlaveReceiver.disableStrictVerification=true
            {code}

            Then I re-launched the JNLP agent using the same command and the connection was established. Likewise, after disabling strict verification, I was able to provision the node via the OpenStack Cloud plugin.

            Disabling strict verification on the DefaultJnlpSlaveReceiver appears to work, is this the correct approach?

            As an aside, creating a permanent node via the JNLP WebStart works and does not require disabling strict verification.

            Thank you for all your hard work.

            Regards,
            Ryan
            Hello,

            I've ran into an issue when launching a windows JNLP agent via the OpenStack Cloud Plugin.

            The OpenStack Plugin was correctly spinning up my VM, but the slave failed to connect to my jenkins master.

            To troubleshoot, I downloaded the slave.jar and launched the JNLP slave manually using this command from the slave node:

            {code:java}
            $ java -jar slave.jar -jnlpUrl http://yourserver:port/computer/slave-name/slave-agent.jnlp
            {code}

            I received the following error:

            {quote}
            INFO: Trying protocol: JNLP-connect
            Jan 23, 2017 12:03:59 PM hudson.remoting.jnlp.Main$CuiListener status
            INFO: Protocol JNLP-connect encountered an unexpected exception
            java.util.concurrent.ExecutionException: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Server didn't
            accept the handshake:
                    at java.util.concurrent.FutureTask.report(Unknown Source)
                    at java.util.concurrent.FutureTask.get(Unknown Source)
                    at hudson.remoting.Engine.innerRun(Engine.java:385)
                    at hudson.remoting.Engine.run(Engine.java:287)
            Caused by: org.jenkinsci.remoting.protocol.impl.ConnectionRefusalException: Server didn't accept the handshake:
                    at org.jenkinsci.remoting.engine.JnlpProtocol1Handler.sendHandshake(JnlpProtocol1Handler.java:121)
                    at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$2.call(LegacyJnlpProtocolHandler.java:162)
                    at org.jenkinsci.remoting.engine.LegacyJnlpProtocolHandler$2.call(LegacyJnlpProtocolHandler.java:158)
                    at java.util.concurrent.FutureTask.run(Unknown Source)
                    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
                    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
                    at hudson.remoting.Engine$1$1.run(Engine.java:94)
                    at java.lang.Thread.run(Unknown Source)

            Jan 23, 2017 12:03:59 PM hudson.remoting.jnlp.Main$CuiListener error
            SEVERE: The server rejected the connection: None of the protocols were accepted
            java.lang.Exception: The server rejected the connection: None of the protocols were accepted
                    at hudson.remoting.Engine.onConnectionRejected(Engine.java:484)
                    at hudson.remoting.Engine.innerRun(Engine.java:448)
                    at hudson.remoting.Engine.run(Engine.java:287)
            {quote}

            When investigating the logs on the Jenkins master, I noticed this:

            {quote}
            INFO: Accepted connection #5 from /10.0.0.24:50749
            Jan 21, 2017 1:18:33 AM jenkins.slaves.DefaultJnlpSlaveReceiver afterProperties
            WARNING: Rejecting connection to dynamic-windows-autogen-1835 from /10.0.0.24:50749 as a JNLP agent as the launcher class jenkins.plugins.openstack.compute.JCloudsLauncher does not extend JNLPLauncher or does not implement DelegatingComputerLauncher with a delegation chain leading to a JNLPLauncher. Set system property jenkins.slaves.DefaultJnlpSlaveReceiver.disableStrictVerification=true to allowconnections until the plugin has been fixed.
            {quote}

            Following the error message, I ran the following command from my jenkin master's groovy script console (http://master/script)

            {code:java}
            jenkins.slaves.DefaultJnlpSlaveReceiver.disableStrictVerification=true
            {code}

            Then I re-launched the JNLP agent using the same command and the connection was established. Likewise, after disabling strict verification, I was able to provision the node via the OpenStack Cloud plugin.

            Disabling strict verification on the DefaultJnlpSlaveReceiver appears to work, is this the correct approach?

            As an aside, creating a permanent node via the JNLP WebStart works and does not require disabling strict verification.

            Thank you for all your hard work.

            Regards,
            Ryan
             
            kslice Kevin McHale made changes -
            Link This issue is duplicated by JENKINS-43043 [ JENKINS-43043 ]

              People

              • Assignee:
                olivergondza Oliver Gond┼ża
                Reporter:
                thornto4 Ryan Thornton
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: