• Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Blocker Blocker
    • core
    • None
    • Master: Hudson ver. 1.363, RHEL Linux 2.6.18-164.el5
      Slaves: RHEL Linux 2.6.9-55.0.2.ELhugemem & Windows XP SP3

      After Hudson update from version 1.361 to 1.363 we occasionally see jobs being triggered twice. This seems to happen in both cases, when upstream job triggers downstream job, and remotely triggering a job via curl in a script.

      All of our jobs are free-style jobs.

          [JENKINS-6819] Jobs are triggered twice occasionally

          tiainpa created issue -

          We encounter same issue. And when it happens the duplicated jobs' views became unreachable (neither the job view, neither any of both build views). Other views on other jobs work fine.

          Julien Carsique added a comment - We encounter same issue. And when it happens the duplicated jobs' views became unreachable (neither the job view, neither any of both build views). Other views on other jobs work fine.
          Andrew Bayer made changes -
          Link New: This issue is duplicated by JENKINS-6825 [ JENKINS-6825 ]
          Andrew Bayer made changes -
          Assignee New: Kohsuke Kawaguchi [ kohsuke ]
          Andrew Bayer made changes -
          Priority Original: Major [ 3 ] New: Blocker [ 1 ]

          Alan Harder added a comment -

          can someone post steps to see the problem in a new install of 1.363?

          Alan Harder added a comment - can someone post steps to see the problem in a new install of 1.363?

          Andrew Bayer added a comment -

          For what it's worth, I'm having trouble reproducing it in a fresh install of 1.363 - I've only seen it in upgrades. I think it's not the dependency graph changes - it seems to be a race condition, possibly related to Kohsuke's refactoring of pgweiss's logic for preventing more or less this exact thing from happening.

          Andrew Bayer added a comment - For what it's worth, I'm having trouble reproducing it in a fresh install of 1.363 - I've only seen it in upgrades. I think it's not the dependency graph changes - it seems to be a race condition, possibly related to Kohsuke's refactoring of pgweiss's logic for preventing more or less this exact thing from happening.

          After downgrading Hudson to 1.362, I can see the two successive builds of same job were run from the same trigger (the builds nuxeo-features-5.3-notests/973/ and 972/ said they were both run from the build nuxeo-jsf-5.3-notests/504).
          These all are Maven jobs, configured to trigger a build when a snapshot dependency is built.

          Julien Carsique added a comment - After downgrading Hudson to 1.362, I can see the two successive builds of same job were run from the same trigger (the builds nuxeo-features-5.3-notests/973/ and 972/ said they were both run from the build nuxeo-jsf-5.3-notests/504). These all are Maven jobs, configured to trigger a build when a snapshot dependency is built.

          On the upstream project (nuxeo-jsf-5.3-notests/504) does it report that it's triggering nuxeo-features-5.3-notests twice?

          Kohsuke Kawaguchi added a comment - On the upstream project (nuxeo-jsf-5.3-notests/504) does it report that it's triggering nuxeo-features-5.3-notests twice?

          Kohsuke Kawaguchi added a comment - - edited

          abayer: I doubt if the concurrent fix change that you refer to can cause this problem. The problem there is that if you actually have two builds of the same job queued (which requires a parameterization), then it's possible that those two builds end up executed concurrently, even if it's supposed to be prohibited.

          In case of this problem, there should be just one build in the queue.

          Still digging deeper...

          Kohsuke Kawaguchi added a comment - - edited abayer: I doubt if the concurrent fix change that you refer to can cause this problem. The problem there is that if you actually have two builds of the same job queued (which requires a parameterization), then it's possible that those two builds end up executed concurrently, even if it's supposed to be prohibited. In case of this problem, there should be just one build in the queue. Still digging deeper...

            kohsuke Kohsuke Kawaguchi
            tiainpa tiainpa
            Votes:
            22 Vote for this issue
            Watchers:
            28 Start watching this issue

              Created:
              Updated:
              Resolved: