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

Launcher's afterDisconnect() method is called twice

XMLWordPrintable

      The call to r.getExecutor().getOwner().disconnect() in vSphereCloudSlave causes vSphereCloudLauncher's afterDisconnect() to be called twice, on separate threads. This means, for instance, that a VM configured to shutdown and revert after a disconnect will do so twice.

      This appears to be an issue with Jenkins itself.

      A temporary fix on my side is the use of an AtomicBoolean to prevent the afterDisconnect from executing its logic twice. Would this be considered an acceptable patch?

          [JENKINS-22740] Launcher's afterDisconnect() method is called twice

          Hossam Rabbouh created issue -
          Hossam Rabbouh made changes -
          Description Original: The call to r.getExecutor().getOwner().disconnect() in vSphereCloudSlave causes vSphereCloudLauncher's afterDisconnect() to be called twice, on separate threads. This means, for instance, that a VM configured to shutdown and revert after a disconnect will do so twice.

          This appears to be an issue with Jenkins itself.

          A temporary fix on my side is the use of an AtomicBoolean to prevent the afterDisconnect from executing its logic twice. Would this be considered an acceptable fix?

                      		New: The call to r.getExecutor().getOwner().disconnect() in vSphereCloudSlave causes vSphereCloudLauncher's afterDisconnect() to be called twice, on separate threads. This means, for instance, that a VM configured to shutdown and revert after a disconnect will do so twice.

          This appears to be an issue with Jenkins itself.

          A temporary fix on my side is the use of an AtomicBoolean to prevent the afterDisconnect from executing its logic twice. Would this be considered an acceptable patch?

           

          Hossam Rabbouh added a comment -

          Looked into it: calling r.getExecutor().getOwner().getChannel().close() instead of r.getExecutor().getOwner().disconnect() fixes this issue. It's a more "brutal" method, but it works.

          I can submit a pull request with this and some other changes tonight, to be reviewed.

          Hossam Rabbouh added a comment - Looked into it: calling r.getExecutor().getOwner().getChannel().close() instead of r.getExecutor().getOwner().disconnect() fixes this issue. It's a more "brutal" method, but it works. I can submit a pull request with this and some other changes tonight, to be reviewed.

          Hossam Rabbouh added a comment -

          Pull request successfully merged; thanks to the team. Fix available in version 1.1.6.

          Hossam Rabbouh added a comment - Pull request successfully merged; thanks to the team. Fix available in version 1.1.6.
          Hossam Rabbouh made changes -
          Fix Version/s New: current [ 10162 ]
          Resolution New: Fixed [ 1 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]
          Giuseppe Landolfi made changes -
          Link New: This issue is duplicated by JENKINS-35272 [ JENKINS-35272 ]
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 154854 ] New: JNJira + In-Review [ 195054 ]
          pjdarton made changes -
          Status Original: Resolved [ 5 ] New: Closed [ 6 ]

            Unassigned Unassigned
            hrabbouh Hossam Rabbouh
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: