• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • other
    • None
    • Platform: All, OS: All

      We have upgraded from Hudson 1.224 to 1.244.
      We had projects set to a quiet period of 2 minutes. And we have svn update
      polling every minute.

      We kept this configuration, but this caused the builder not to build at all. It
      kept the job in the queue for every. It got reset every time (also without
      check-ins).
      We had to remove the quiet period to get it building.

          [JENKINS-2180] Quiet period keeps running without building

          Cees Bos created issue -

          dgreen added a comment -

          we have also experienced the same problem.

          dgreen added a comment - we have also experienced the same problem.

          acronce added a comment -

          I just ran into the same problem where we had our polling interval set to a minute, and a quiet period set
          to 10 minutes. This seems like a reasonable configuration, but builds are getting stuck.

          acronce added a comment - I just ran into the same problem where we had our polling interval set to a minute, and a quiet period set to 10 minutes. This seems like a reasonable configuration, but builds are getting stuck.

          dgreen added a comment -

          as a workaround what we've done is eliminate the quite period and set the polling interval to what was
          previously the quiet period. This doesn't have exactly the same effect, but for our purposes it has worked
          pretty well so far.

          dgreen added a comment - as a workaround what we've done is eliminate the quite period and set the polling interval to what was previously the quiet period. This doesn't have exactly the same effect, but for our purposes it has worked pretty well so far.

          Alan Harder added a comment -

          Copying my comment from related issue #2671:

          I can confirm this behavior. What's happening:

          In case of equal SCM-poll schedule and quiet period: initial quiet period ends
          and a build starts, and at the same time another SCM-poll starts. The SCM-poll
          thinks there are still new changes because it runs before the new build has a
          chance to update the job workspace with the latest changes from the repository.
          So that build runs AND a new one is scheduled (quiet period begins).

          Another variation: if the quiet period is slightly longer than the SCM poll
          schedule then a build never starts.. every SCM poll sees new changes and then
          extends the quiet period of the waiting job, so the quiet period never completes.

          WORKAROUND to avoid either issue: always keep quiet period at least 5-15 seconds
          shorter than any SCM-polling schedule/interval (however long SCM updates take).
          This gives the newly-started job time to update the job workspace before the
          next SCM poll.

          SOLUTION for these issues? Not sure.. perhaps some locking on the SCM-poll to
          prevent it from running if a build has started, but not yet updated the
          workspace. There's already some locking code around SCM-poll, so maybe it could
          be updated for this case.
          For the 2nd variation, there are a few options:

          • don't extend quiet period.. this would allow a build to start. easiest to
            implement; small change in Queue.add()
          • to keep extend-QP the SCM-poll would need some way to distinguish
            changes-vs-job-workspace from changes-since-last-poll, and only extend quiet
            period for the latter. not sure how this would work..

          Alan Harder added a comment - Copying my comment from related issue #2671: I can confirm this behavior. What's happening: In case of equal SCM-poll schedule and quiet period: initial quiet period ends and a build starts, and at the same time another SCM-poll starts. The SCM-poll thinks there are still new changes because it runs before the new build has a chance to update the job workspace with the latest changes from the repository. So that build runs AND a new one is scheduled (quiet period begins). Another variation: if the quiet period is slightly longer than the SCM poll schedule then a build never starts.. every SCM poll sees new changes and then extends the quiet period of the waiting job, so the quiet period never completes. WORKAROUND to avoid either issue: always keep quiet period at least 5-15 seconds shorter than any SCM-polling schedule/interval (however long SCM updates take). This gives the newly-started job time to update the job workspace before the next SCM poll. SOLUTION for these issues? Not sure.. perhaps some locking on the SCM-poll to prevent it from running if a build has started, but not yet updated the workspace. There's already some locking code around SCM-poll, so maybe it could be updated for this case. For the 2nd variation, there are a few options: don't extend quiet period.. this would allow a build to start. easiest to implement; small change in Queue.add() to keep extend-QP the SCM-poll would need some way to distinguish changes-vs-job-workspace from changes-since-last-poll, and only extend quiet period for the latter. not sure how this would work..

          Alan Harder added a comment -
              • Issue 2382 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment - Issue 2382 has been marked as a duplicate of this issue. ***
          Alan Harder made changes -
          Link New: This issue is duplicated by JENKINS-2382 [ JENKINS-2382 ]

          Alan Harder added a comment -
              • Issue 2626 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment - Issue 2626 has been marked as a duplicate of this issue. ***
          Alan Harder made changes -
          Link New: This issue is duplicated by JENKINS-2626 [ JENKINS-2626 ]

          Alan Harder added a comment -
              • Issue 2530 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment - Issue 2530 has been marked as a duplicate of this issue. ***

            kohsuke Kohsuke Kawaguchi
            cbos Cees Bos
            Votes:
            19 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: