• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • core

      Do a fresh install of Jenkins. Make 3+ executors.

      Create project A, with downstream B.
      Have it `sleep 15`.

      Create project B, with downstream C.
      Set it to block on building upstream projects.
      Have it `sleep 30`.

      Create project C.
      Set it to block on building upstream projects.
      Have it `sleep 30`.

      Trigger A, B, and C together, in succession.

      As A builds, notice that C is blocked, and waits for the (transitive) upstream project A to finish.

      However, once A finished, B and C both start!

      Only B should have started. C should have stayed blocked until B finished. Instead, C behaved as if A – and A alone – were the upstream project.

          [JENKINS-27871] Block on upstream projects does not work

          Paul Draper created issue -

          Paul Draper added a comment -

          I have found that this bug is present in 1.608, but not in 1.596.2.

          Paul Draper added a comment - I have found that this bug is present in 1.608, but not in 1.596.2.
          Paul Draper made changes -
          Priority Original: Minor [ 4 ] New: Critical [ 2 ]

          Daniel Beck added a comment -

          Could you test Jenkins 1.606 and 1.607 to see whether this was introduced in the latter?

          Be aware that downgrading from 1.607+ to 1.605 or earlier will lose slave configuration.

          Daniel Beck added a comment - Could you test Jenkins 1.606 and 1.607 to see whether this was introduced in the latter? Be aware that downgrading from 1.607+ to 1.605 or earlier will lose slave configuration.

          I suspect that this is a bug introduced in Jenkins Core in 1.536 but which would only be visible on a single core non-hyperthreaded master or on a very highly contended master until Jenkins 1.607

          It seems similar to the issue in https://issues.jenkins-ci.org/browse/JENKINS-27708

          I may have an idea for a hack to solve this type of issue... I'll do some thinking

          Stephen Connolly added a comment - I suspect that this is a bug introduced in Jenkins Core in 1.536 but which would only be visible on a single core non-hyperthreaded master or on a very highly contended master until Jenkins 1.607 It seems similar to the issue in https://issues.jenkins-ci.org/browse/JENKINS-27708 I may have an idea for a hack to solve this type of issue... I'll do some thinking
          Stephen Connolly made changes -
          Link New: This issue is related to JENKINS-27708 [ JENKINS-27708 ]

          Paul Draper added a comment - - edited

          Yes 1.607 is the first affected version.

          @stephenconnolly, I bisected it to 92147c3597308bc05e6448ccc41409fcc7c05fd7.

          I'd take a crack at it, but seeing the author of that commit, I'm sure you'd be far better at this

          Paul Draper added a comment - - edited Yes 1.607 is the first affected version. @stephenconnolly, I bisected it to 92147c3597308bc05e6448ccc41409fcc7c05fd7 . I'd take a crack at it, but seeing the author of that commit, I'm sure you'd be far better at this

          Can you see if the "hack" I have made in http://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/jenkins-war/1.609-SNAPSHOT/jenkins-war-1.609-20150410.091817-1.war resolves this issue for you?

          diff --git a/core/src/main/java/hudson/model/Queue.java b/core/src/main/java/hudson/model/Queue.java
          index d776a57..6a5e006 100644
          --- a/core/src/main/java/hudson/model/Queue.java
          +++ b/core/src/main/java/hudson/model/Queue.java
          @@ -1335,7 +1335,10 @@ public class Queue extends ResourceController implements Saveable {
                       final QueueSorter s = sorter;
                       if (s != null)
                           s.sortBuildableItems(buildables);
          -
          +            
          +            // JENKINS-27708, JENKINS-27871, etc
          +            updateSnapshot();
          +            
                       // allocate buildable jobs to executors
                       for (BuildableItem p : new ArrayList<BuildableItem>(
                               buildables)) {// copy as we'll mutate the list in the loop
          @@ -1372,6 +1375,9 @@ public class Queue extends ResourceController implements Saveable {
                               makePending(p);
                           else
                               LOGGER.log(Level.FINE, "BuildableItem {0} with empty work units!?", p);
          +                                
          +                // JENKINS-27708, JENKINS-27871, etc
          +                updateSnapshot();
                       }
                   } finally { updateSnapshot(); } } finally {
                       lock.unlock();
          

          Stephen Connolly added a comment - Can you see if the "hack" I have made in http://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/jenkins-war/1.609-SNAPSHOT/jenkins-war-1.609-20150410.091817-1.war resolves this issue for you? diff --git a/core/src/main/java/hudson/model/Queue.java b/core/src/main/java/hudson/model/Queue.java index d776a57..6a5e006 100644 --- a/core/src/main/java/hudson/model/Queue.java +++ b/core/src/main/java/hudson/model/Queue.java @@ -1335,7 +1335,10 @@ public class Queue extends ResourceController implements Saveable { final QueueSorter s = sorter; if (s != null ) s.sortBuildableItems(buildables); - + + // JENKINS-27708, JENKINS-27871, etc + updateSnapshot(); + // allocate buildable jobs to executors for (BuildableItem p : new ArrayList<BuildableItem>( buildables)) { // copy as we'll mutate the list in the loop @@ -1372,6 +1375,9 @@ public class Queue extends ResourceController implements Saveable { makePending(p); else LOGGER.log(Level.FINE, "BuildableItem {0} with empty work units!?" , p); + + // JENKINS-27708, JENKINS-27871, etc + updateSnapshot(); } } finally { updateSnapshot(); } } finally { lock.unlock();

          Jesse Glick added a comment -

          If it is this easy to reproduce, should be easy to write a test for it too, no?

          Jesse Glick added a comment - If it is this easy to reproduce, should be easy to write a test for it too, no?

          @Paul Draper, try Jenkins 1.536 with a single core non-hyper-threaded master and you should see (I'm 95% certain) that the issue is there but not in 1.534 (as 1.535 was a borked release)

          Stephen Connolly added a comment - @Paul Draper, try Jenkins 1.536 with a single core non-hyper-threaded master and you should see (I'm 95% certain) that the issue is there but not in 1.534 (as 1.535 was a borked release)

            stephenconnolly Stephen Connolly
            draperp Paul Draper
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: