Unable to lock/release more than once from the same pool within a task

[jdeppe-pivotal]

Within a single task I'd like to be able to grab more than one lock from a pool. It seems that I am able to acquire multiple locks (say two), but when releasing them, the second one produces this error: error releasing lock: open /tmp/build/put/gf1-lock/name: no such file or directory. I'm assuming that the acquired locks also didn't work correctly and probably overwrote each other.

[concourse-bot]

Hi there!

We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created.

The current status is as follows:

• #102950930 Unable to lock/release more than once from the same pool within a task

This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.

[vito]

Could you include the build plan that didn't work?

[jdeppe-pivotal]

Sure:

  - name: deploy-releases
    serial: true
    plan:
      - put: gf1-lock
        params:
          acquire: true
      - put: gf1-lock
        params:
          acquire: true
      - aggregate:
        - get: cf-gemfire-cli
          trigger: true
          passed:
            - cli-unit-tests
        - get: testing-release
          trigger: true
          passed:
            - build-testing-release
        - get: testing-release-version
          passed:
            - build-testing-release
        - get: gemfire-release
          trigger: true
          passed:
            - build-gemfire-release
        - get: gemfire-release-version
          passed:
            - build-gemfire-release
        - get: broker-release
          trigger: true
          passed:
            - build-broker-release
        - get: broker-release-version
          trigger: true
          passed:
            - build-broker-release
        - get: broker-registrar-release
          trigger: true
          passed:
            - build-broker-registrar-release
        - get: broker-registrar-release-version
          passed:
            - build-broker-registrar-release
        - get: cf-gemfire-ci
      - task: build
        privileged: true
        file: cf-gemfire-ci/concourse/cf-gemfire-testing/deploy-releases.yml
        ensure:
          do:
            put: gf1-lock
            params:
              release: gf1-lock
            put: gf1-lock
            params:
              release: gf1-lock

[vito]

You'll run into problems with having the same step name multiple times. If you're getting the same lock twice you'll want to name them differently so you can release the individually acquired ones, like so:

- put: lock-1
  resource: gf1-lock
  params: {acquire: true}
- put: lock-2
  resource: gf1-lock
  params: {acquire: true}
# ...
- put: release-lock-1
  resource: gf1-lock
  params: {release: lock-1}
- put: release-lock-2
  resource: gf1-lock
  params: {release: lock-2}

This doesn't matter for the single-lock case since at that point there's no name conflict. Technically there's weirdness since the acquire and release steps often have the same name for terseness' sake, but it doesn't become an issue until you have multiple locks.

[jdeppe-pivotal]

Thanks for that - it certainly improves the clarity. However, the problem still remains. Initially I had hoped that it would be fixed as I thought that each put element would exist in its own container and thus there would be no conflicts. I guess that it's only the resource itself that exists in a separate (single) container regardless of how many times it my be referenced by uniquely named puts.

[vito]

No, you're correct; each put is its own container. So it still failed with
the config I suggested? Can you post more info (screenshots/pipeline
config)? That should totally work.

On Mon, Sep 21, 2015, 9:18 AM Jens Deppe notifications@github.com wrote:

Thanks for that - it certainly improves the clarity. However, the problem
still remains. Initially I had hoped that it would be fixed as I thought
that each put element would exist in its own container and thus there
would be no conflicts. I guess that it's only the resource itself that
exists in a separate (single) container regardless of how many times it my
be referenced by uniquely named puts.

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

[jdeppe-pivotal]

Here is the job definition:

  - name: deploy-releases
    serial: true
    plan:
      - put: deploy-acquire-lock-1
        resource: gf1-lock
        params:
          acquire: true
      - put: deploy-acquire-lock-2
        resource: gf1-lock
        params:
          acquire: true
      - aggregate:
        - get: cf-gemfire-cli
          passed:
            - cli-unit-tests
          trigger: true
        - get: gemfire-release
          trigger: true
          passed:
            - build-gemfire-release
        - get: gemfire-release-version
          passed:
            - build-gemfire-release
        - get: broker-release
          trigger: true
          passed:
            - build-broker-release
        - get: broker-release-version
          trigger: true
          passed:
            - build-broker-release
        - get: broker-registrar-release
          trigger: true
          passed:
            - build-broker-registrar-release
        - get: broker-registrar-release-version
          passed:
            - build-broker-registrar-release
        - get: cf-gemfire-ci
      - task: build
        privileged: true
        file: cf-gemfire-ci/concourse/cf-gemfire-testing/deploy-releases.yml
        ensure:
          do:
            - put: deploy-release-lock-1
              resource: gf1-lock
              params:
                release: gf1-lock
            - put: deploy-release-lock-2
              resource: gf1-lock
              params:
                release: gf1-lock

The error for deploy-release-lock-1 is:

error releasing lock: open /tmp/build/put/gf1-lock/name: no such file or directory

Also attached is a screenshot for the acquire steps

[vito]

Your release config needs to say release: deploy-acquire-lock-1 and release: deploy-acquire-lock-2 respectively, to refer to the locks acquired earlier on.

[jdeppe-pivotal]

Of course! No surprise that it was EBCAK after all. It would be nice if the examples would be a little more verbose so as to leave less room for error :). Thanks for the help.

[vito]

Updated the docs!

[SaurabhQA]

Hi,

I have a sequence of jobs in my pipeline say Job-1 and Job2. I was able to acquire two locks in Job1. I want to release the locks in job2. Getting the below error while releasing the lock.Could you please suggest how to resolve it. It works fine if aquire and release are part of one job.

error releasing lock: open /tmp/build/put/lock-1/name

Below is the pipeline

jobs:

• name: job1
  plan:
  • get: sample
    trigger: true
  • put: lock-1
    resource: lockRes
    params: {acquire: true}
  • put: lock-2
    resource: lockRes
    params: {acquire: true}
  • task: tests
    file: sample/buildTest.yml
• name: job-B
  serial: true
  plan:
  • get: sample
  • task: tests
    file: sample/buildTest.yml
  • put: release-lock-1
    resource: lockRes
    params: {release: lock-1}
  • put: release-lock-2
    resource: lockRes
    params: {release: lock-2}