When executing builds in parallel*, some post-build actions force the builds to end in the same order they were started. Even if build #2 is ready, it has to wait until build #1 is done. Claim plugin is one such plugin that serializes build order.

      Would it be possible to fix the plugin such that it would not block later builds from finishing even if earlier build was still ongoing?

      *) option "Execute concurrent builds if necessary" in project configuration

      "Executor #4 for master : executing project-x #2 : waiting for Check point hudson.plugins.claim.ClaimPublisher on project-x #1" Id=96 Group=main WAITING on hudson.model.Run$RunExecution$CheckpointSet@3fd2670d
      	at java.lang.Object.wait(Native Method)
      	-  waiting on hudson.model.Run$RunExecution$CheckpointSet@3fd2670d
      	at java.lang.Object.wait(Object.java:485)
      	at hudson.model.Run$RunExecution$CheckpointSet.waitForCheckPoint(Run.java:1453)
      	at hudson.model.Run.waitForCheckpoint(Run.java:1411)
      	at hudson.model.CheckPoint.block(CheckPoint.java:144)
      	at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:25)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:774)
      	at hudson.model.Build$BuildExecution.post2(Build.java:183)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:724)
      	at hudson.model.Run.execute(Run.java:1617)
      	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      	at hudson.model.ResourceController.execute(ResourceController.java:88)
      	at hudson.model.Executor.run(Executor.java:237)
      

          [JENKINS-19820] Claim plugin serializes concurrent builds

          Sami Salonen created issue -
          Sami Salonen made changes -
          Link New: This issue is related to JENKINS-9913 [ JENKINS-9913 ]
          Sami Salonen made changes -
          Description Original: When executing builds in parallel*, some post-build actions force the builds to end in the same order they were started. Even if build #2 is ready, it has to wait until build #1 is done. Claim plugin is one such plugin that serializes build order. This is related to JENKINS-9913.

          Would it be possible to fix the plugin such that it would not block later builds from finishing even if earlier build was still ongoing?

          *) option "Execute concurrent builds if necessary" in project configuration

          {code}
          "Executor #4 for master : executing project-x #2 : waiting for Check point hudson.plugins.claim.ClaimPublisher on project-x #1" Id=96 Group=main WAITING on hudson.model.Run$RunExecution$CheckpointSet@3fd2670d
          at java.lang.Object.wait(Native Method)
          - waiting on hudson.model.Run$RunExecution$CheckpointSet@3fd2670d
          at java.lang.Object.wait(Object.java:485)
          at hudson.model.Run$RunExecution$CheckpointSet.waitForCheckPoint(Run.java:1453)
          at hudson.model.Run.waitForCheckpoint(Run.java:1411)
          at hudson.model.CheckPoint.block(CheckPoint.java:144)
          at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:25)
          at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802)
          at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:774)
          at hudson.model.Build$BuildExecution.post2(Build.java:183)
          at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:724)
          at hudson.model.Run.execute(Run.java:1617)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
          at hudson.model.ResourceController.execute(ResourceController.java:88)
          at hudson.model.Executor.run(Executor.java:237)
          {code}
          New: When executing builds in parallel*, some post-build actions force the builds to end in the same order they were started. Even if build #2 is ready, it has to wait until build #1 is done. Claim plugin is one such plugin that serializes build order.

          Would it be possible to fix the plugin such that it would not block later builds from finishing even if earlier build was still ongoing?

          *) option "Execute concurrent builds if necessary" in project configuration

          {code}
          "Executor #4 for master : executing project-x #2 : waiting for Check point hudson.plugins.claim.ClaimPublisher on project-x #1" Id=96 Group=main WAITING on hudson.model.Run$RunExecution$CheckpointSet@3fd2670d
          at java.lang.Object.wait(Native Method)
          - waiting on hudson.model.Run$RunExecution$CheckpointSet@3fd2670d
          at java.lang.Object.wait(Object.java:485)
          at hudson.model.Run$RunExecution$CheckpointSet.waitForCheckPoint(Run.java:1453)
          at hudson.model.Run.waitForCheckpoint(Run.java:1411)
          at hudson.model.CheckPoint.block(CheckPoint.java:144)
          at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:25)
          at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802)
          at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:774)
          at hudson.model.Build$BuildExecution.post2(Build.java:183)
          at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:724)
          at hudson.model.Run.execute(Run.java:1617)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
          at hudson.model.ResourceController.execute(ResourceController.java:88)
          at hudson.model.Executor.run(Executor.java:237)
          {code}

          Daniel Beck added a comment -

          Probably because of: "Claims may be made sticky to follow the user claiming the failure until the build is successful again."

          If build N fails and is claimed sticky, result of build N+1 needs to be known to determine whether the claim extends to N+2; so the latter cannot finish before the former.

          Daniel Beck added a comment - Probably because of: "Claims may be made sticky to follow the user claiming the failure until the build is successful again." If build N fails and is claimed sticky, result of build N+1 needs to be known to determine whether the claim extends to N+2; so the latter cannot finish before the former.

          This issue can't be fixed without removing the sticky functionality

          Christian Bremer added a comment - This issue can't be fixed without removing the sticky functionality
          Christian Bremer made changes -
          Resolution New: Won't Fix [ 2 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

          Daniel Beck added a comment -

          Christian: Would it be possible to make this conditional on sticky being enabled?

          Daniel Beck added a comment - Christian: Would it be possible to make this conditional on sticky being enabled?

          I think it is possible, although as I see it the sticky functionality is very central and something that most(if not all) users would like.

          A user already has the option to not use that claim plugin at all if it wants true concurrents builds.

          Christian Bremer added a comment - I think it is possible, although as I see it the sticky functionality is very central and something that most(if not all) users would like. A user already has the option to not use that claim plugin at all if it wants true concurrents builds.

          Marc Carter added a comment -

          Surely this is resolvable in the code. If build succeeds we don't care about preceeding Claims. If build fails we register a listener on previous build and update the claim as appropriate. This would be rather more delicate code but entirely doable.

          Marc Carter added a comment - Surely this is resolvable in the code. If build succeeds we don't care about preceeding Claims. If build fails we register a listener on previous build and update the claim as appropriate. This would be rather more delicate code but entirely doable.

          Sean Flanigan added a comment -

          If the behaviour won't be changed, I think the inline configuration help for "Allow broken build claiming" should warn the user that concurrent builds will be affected.

          Sean Flanigan added a comment - If the behaviour won't be changed, I think the inline configuration help for "Allow broken build claiming" should warn the user that concurrent builds will be affected.
          Sean Flanigan made changes -
          Resolution Original: Won't Fix [ 2 ]
          Status Original: Resolved [ 5 ] New: Reopened [ 4 ]

            Unassigned Unassigned
            salsa Sami Salonen
            Votes:
            2 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: