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

Locked resources using the variable parameter do not get reset to the variable once released to another requester and only appear as null on subsequent locks

    XMLWordPrintable

Details

    Description

      I'm appearing to hit an issue where a released resource does not get an update on the environment variable once the lock is released.  See the following code (with only two resources available in the automation-accounts label)

       

      node {
        parallel (
          "p1": {
            lock(label: 'automation-accounts', variable: 'ACCOUNTS_VAR', quantity: 1) {
              echo "A $env.ACCOUNTS_VAR"
              sleep 4
                   }
          },
          "p2": {
            lock(label: 'automation-accounts', variable: 'ACCOUNTS_VAR', quantity: 1) {
              echo "B $env.ACCOUNTS_VAR"
              sleep 2
                   }
          },
          "p3": {
            lock(label: 'automation-accounts', variable: 'ACCOUNTS_VAR', quantity: 1) {
              echo "C $env.ACCOUNTS_VAR"
                   }
               }
        )
      }

       

      In the log I get the following (note "C null"):
      [Pipeline] {
      [Pipeline] parallel
      [Pipeline] [p1] { (Branch: p1)
      [Pipeline] [p2] { (Branch: p2)
      [Pipeline] [p3] { (Branch: p3)
      [Pipeline] [p1] lock
      [p1] Trying to acquire lock on [Label: automation-accounts, Quantity: 1]
      [p1] Lock acquired on [Label: automation-accounts, Quantity: 1]
      [Pipeline] [p1] {
      [Pipeline] [p2] lock
      [p2] Trying to acquire lock on [Label: automation-accounts, Quantity: 1]
      [p2] Lock acquired on [Label: automation-accounts, Quantity: 1]
      [Pipeline] [p2] {
      [Pipeline] [p3] lock
      [p3] Trying to acquire lock on [Label: automation-accounts, Quantity: 1]
      [p3] Found 0 available resource(s). Waiting for correct amount: 1.
      [p3] [Label: automation-accounts, Quantity: 1] is locked, waiting...
      [Pipeline] [p1] echo
      [p1] A <Account1>
      [Pipeline] [p1] sleep
      [p1] Sleeping for 4 sec
      [Pipeline] [p2] echo
      [p2] B <Account2>
      [Pipeline] [p2] sleep
      [p2] Sleeping for 2 sec
      [p3] Lock acquired on [Label: automation-accounts, Quantity: 1]
      [Pipeline] [p2] }
      [p2] Lock released on resource [Label: automation-accounts, Quantity: 1]
      [Pipeline] [p3] {
      [Pipeline] [p2] // lock
      [Pipeline] [p2] }
      [Pipeline] [p3] echo
      [p3] C null
      [Pipeline] [p3] }
      [p3] Lock released on resource [Label: automation-accounts, Quantity: 1]
      [Pipeline] [p3] // lock
      [Pipeline] [p3] }
      [Pipeline] [p1] }
      [p1] Lock released on resource [Label: automation-accounts, Quantity: 1]
      [Pipeline] [p1] // lock
      [Pipeline] [p1] }
      [Pipeline] // parallel
      [Pipeline] }
      [Pipeline] // node
      [Pipeline] End of Pipeline

      Expected Result:
      I should get "C <Account2>

      Perhaps I'm calling it wrong though?  It appears that the lock is being acquired BEFORE the resource is released though this might be just a logging complication of calling it in parallel

      Attachments

        Issue Links

          Activity

            yes its active ,see some bug fixes going in , we use it for our CI pipeline in validation stage. 

            vikashks vikash srivastava added a comment - yes its active ,see some bug fixes going in , we use it for our CI pipeline in validation stage. 

            vikashks the reason for my question is that since June 2018 I could only see a security fix released in March and one bug fixed in Jan. And all pull requests, except one, have failed the CI build after the last release: https://github.com/jenkinsci/lockable-resources-plugin/pulls

            I have also browsed 5-6 PRs in the list above, and they all seem to be waiting for comments or actions from maintainers for a few months, including the PR that fixes this issue.

            adriancjr Adrian Constantin added a comment - vikashks the reason for my question is that since June 2018 I could only see a security fix released in March and one bug fixed in Jan. And all pull requests, except one, have failed the CI build after the last release:  https://github.com/jenkinsci/lockable-resources-plugin/pulls I have also browsed 5-6 PRs in the list above, and they all seem to be waiting for comments or actions from maintainers for a few months, including the PR that fixes this issue.
            carlosgarcia Carlos Garcia added a comment -

            The same issue is reproduced in my environment. Does anybody know if there is a feasible solution? Is there any release planned to address this issue?

            carlosgarcia Carlos Garcia added a comment - The same issue is reproduced in my environment. Does anybody know if there is a feasible solution? Is there any release planned to address this issue?

            There is a workaround (of sorts) which we deployed in our environment (we are using a declarative pipeline): put a loop around the lock statement which breaks out only once the variable is set successfully. It means you lose the FIFO property, and occasionally it can deadlock if there are a lot of waiters, but in a low-contention case the waiter will loop and on the second iteration the lock will be free so it will get it and set the variable.

            haw777 Christopher Head added a comment - There is a workaround (of sorts) which we deployed in our environment (we are using a declarative pipeline): put a loop around the lock statement which breaks out only once the variable is set successfully. It means you lose the FIFO property, and occasionally it can deadlock if there are a lot of waiters, but in a low-contention case the waiter will loop and on the second iteration the lock will be free so it will get it and set the variable.
            vikashks vikash srivastava added a comment - - edited Below changeset is fixing this issue. https://github.com/jenkinsci/lockable-resources-plugin/pull/117/files/2802f118e7957429d0664d24584343b94ba5d51f  

            People

              tgr Tobias Gruetzmacher
              avidviewer Brandon Saunders
              Votes:
              26 Vote for this issue
              Watchers:
              28 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: