• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • build-blocker-plugin
    • None
    • Jenkins 1.611 - 1.617 => ... , BuildBlockerPlugin 1.6

      We´re using the build blocker plugin to prevent certain jobs to be processed at the same time. There jobs are triggered indepenently by time or commits to the scm. From time to time, jobs get stuck in the queue.

      What I noticed is, that jobs get stuck in the queue, in case more than one job gets queued up, eg. because one job is currently processed, which blocks the second job, and now the third one gets triggered. In case only one job gets queued up, everything looks fine.

      Let me know if I can add more information which help working on this issue.

      Help is greatly appreciated...

          [JENKINS-28376] jobs get stuck in queue from time to time

          Added a link to JENKINS-27708, because the behavior described in some of the comments sound very similar.

          Dirk von Husen added a comment - Added a link to JENKINS-27708 , because the behavior described in some of the comments sound very similar.

          Manni added a comment -

          The strange thing (at least on our instance) is that the queued jobs show no reason for being blocked. Usually, when the build blocker plugin blocks job A because job B is running, the Build Queue widget will accurately reflect this. But now jobs simply end up in the queue and the widget will give no reason for them being blocked.

          Manni added a comment - The strange thing (at least on our instance) is that the queued jobs show no reason for being blocked. Usually, when the build blocker plugin blocks job A because job B is running, the Build Queue widget will accurately reflect this. But now jobs simply end up in the queue and the widget will give no reason for them being blocked.

          Yep, same thing here. First the widget shows the reason why the builds are blocked ('blocked by ...'), but when the blocking build is done and the next job could be dequeued, the content of the widget changes and only shows something like 'processed'...

          Our instance here runs on german, so actually I do not know the exact descriptions in english....

          Dirk von Husen added a comment - Yep, same thing here. First the widget shows the reason why the builds are blocked ('blocked by ...'), but when the blocking build is done and the next job could be dequeued, the content of the widget changes and only shows something like 'processed'... Our instance here runs on german, so actually I do not know the exact descriptions in english....

          Daniel Beck added a comment -

          Our instance here runs on german, so actually I do not know the exact descriptions in english....

          The UI uses whatever your browser is set to send as Accept-Language (unless something like the Locale Plugin is installed).

          Daniel Beck added a comment - Our instance here runs on german, so actually I do not know the exact descriptions in english.... The UI uses whatever your browser is set to send as Accept-Language (unless something like the Locale Plugin is installed).

          Darren Carr added a comment -

          Same problem here but the behaviour is consistent and all was fine until we upgraded to Jenkins 1.611
          We are using build blocker plugin 1.6

          I have recreated with three jobs in order to troubleshoot:

          1) Trinity-Job1
          2) Trinity-Job2
          3) Trinity-Job3

          All jobs are restricted to a slave machine which is restricted to have only 2 executors. This is so that only one of these jobs and its downstream project will run on a slave at any one time. All jobs are use the following regex in the build blocker plugin: Trinity.*

          To replicate I kick off all three jobs:

          Job1 runs and Job2, Job 3 queue as normal stating they are waiting for Trinity-Job1 to complete
          When Job1 completes, Job2, Job3 remain queued with no status in the widget - It just states the job is paused with the time elapsed

          However If I kill Job2 in the queue, Job3 kicks off therefore it doesn't like it when there are more then 2 jobs queued.

          Any help would be great.

          Darren Carr added a comment - Same problem here but the behaviour is consistent and all was fine until we upgraded to Jenkins 1.611 We are using build blocker plugin 1.6 I have recreated with three jobs in order to troubleshoot: 1) Trinity-Job1 2) Trinity-Job2 3) Trinity-Job3 All jobs are restricted to a slave machine which is restricted to have only 2 executors. This is so that only one of these jobs and its downstream project will run on a slave at any one time. All jobs are use the following regex in the build blocker plugin: Trinity.* To replicate I kick off all three jobs: Job1 runs and Job2, Job 3 queue as normal stating they are waiting for Trinity-Job1 to complete When Job1 completes, Job2, Job3 remain queued with no status in the widget - It just states the job is paused with the time elapsed However If I kill Job2 in the queue, Job3 kicks off therefore it doesn't like it when there are more then 2 jobs queued. Any help would be great.

          We upgraded to Jenkins 1.614 yesterday. Looks like the problem still exists also in this version.

          Dirk von Husen added a comment - We upgraded to Jenkins 1.614 yesterday. Looks like the problem still exists also in this version.

          Daniel Beck added a comment -

          Please upgrade to 1.618 once it's available. It will contain a fix for JENKINS-28926.

          Daniel Beck added a comment - Please upgrade to 1.618 once it's available. It will contain a fix for JENKINS-28926 .

          Dirk von Husen added a comment - - edited

          Seems like 1.618 fixed the problem. Thank you

          Dirk von Husen added a comment - - edited Seems like 1.618 fixed the problem. Thank you

            Unassigned Unassigned
            dvh_yxlon Dirk von Husen
            Votes:
            4 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: