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

Claim plugin serializes concurrent builds

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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)
      

        Attachments

          Issue Links

            Activity

            Hide
            danielbeck 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.

            Show
            danielbeck 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.
            Hide
            ki82 Christian Bremer added a comment -

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

            Show
            ki82 Christian Bremer added a comment - This issue can't be fixed without removing the sticky functionality
            Hide
            danielbeck Daniel Beck added a comment -

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

            Show
            danielbeck Daniel Beck added a comment - Christian: Would it be possible to make this conditional on sticky being enabled?
            Hide
            ki82 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.

            Show
            ki82 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.
            Hide
            drekbour 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.

            Show
            drekbour 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.
            Hide
            seanf 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.

            Show
            seanf 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.
            Hide
            seanf Sean Flanigan added a comment -

            I'm not using Claim plugin at present, but I think JENKINS-27206 (Pipeline support) touched on this part of the code. From the look of it, sticky claims might unstick when concurrent builds are running.

            Show
            seanf Sean Flanigan added a comment - I'm not using Claim plugin at present, but I think JENKINS-27206 (Pipeline support) touched on this part of the code. From the look of it, sticky claims might unstick when concurrent builds are running.

              People

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

                Dates

                Created:
                Updated: