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

nextBuildNumber not updated when reload configuration

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Steps to Reproduce:
      1) Create a Freestyle Job. Add a "sleep 120" command to the job.
      2) Execute the Freestyle Job twice. One instance will execute, the other instance will be in the queue.
      3) While first instance is executing issue "Reload From Disk Command" either via Browser, CLI, or Manage Jenkins Menu
      4) Wait till both instances complete execution.
      5) Execute the Freestyle Job once more

      At this point you will receive a Dead Thread, with the following:
      java.lang.IllegalStateException: /var/lib/jenkins/jobs/Long Run Job/builds/2 already existed; will not overwrite with Long Run Job #2
      at hudson.model.RunMap.put(RunMap.java:188)
      at jenkins.model.lazy.LazyBuildMixIn.newBuild(LazyBuildMixIn.java:176)
      at hudson.model.AbstractProject.newBuild(AbstractProject.java:1019)
      at hudson.model.AbstractProject.createExecutable(AbstractProject.java:1210)
      at hudson.model.AbstractProject.createExecutable(AbstractProject.java:145)
      at hudson.model.Executor$1.call(Executor.java:364)
      at hudson.model.Executor$1.call(Executor.java:346)
      at hudson.model.Queue._withLock(Queue.java:1405)
      at hudson.model.Queue.withLock(Queue.java:1270)
      at hudson.model.Executor.run(Executor.java:346)

      Three instances of the job have been tried to run. The first instance completed successfully, however the second instance, the one that was pending in the queue during the Reload Configuration From Disk, succeeded, however the nextBuildNumber will not be incremented to 3, but will remain 2.

      When the third instance the one that fails immediately with the above exception, it is trying to use 2 instead of because the nextBuildNumber says 2 is the correct value.

      Also if at the time of the "Reload Configuration from Disk" is executed, there are X number of copies of the same job in the Queue, pending execution, all of these will properly execute afterward, however, that job will fail X number times after those have completed.

        Attachments

          Issue Links

            Activity

            jeff_a_miller Jeff Miller created issue -
            Hide
            jglick Jesse Glick added a comment -

            Duplicate of something already filed.

            Show
            jglick Jesse Glick added a comment - Duplicate of something already filed.
            Hide
            jeff_a_miller Jeff Miller added a comment -

            FYI - this is reproduced with a clean 1.642.3 Install on Red Hat with NO additional plugins, and No changes in the plugins.

            Show
            jeff_a_miller Jeff Miller added a comment - FYI - this is reproduced with a clean 1.642.3 Install on Red Hat with NO additional plugins, and No changes in the plugins.
            Hide
            jeff_a_miller Jeff Miller added a comment -

            Further investigation it appears, that when a job has pending builds, and a reload is done the hudson.model.Run object in the pending build queue, points back to the hudson.model.Job object. When a reload is done, a new hudson.model.Job is created and that is used for new builds. This results in a build number being used that is a duplicate of the the builds that were in the pending build queue when the reload was done.

            The hudson.model.Job needs to have a reload, where it will update correctly including the nextBuildNumber, to provide the hudson.model.Run objects in the pending build queue a valid object to point back to.

            Show
            jeff_a_miller Jeff Miller added a comment - Further investigation it appears, that when a job has pending builds, and a reload is done the hudson.model.Run object in the pending build queue, points back to the hudson.model.Job object. When a reload is done, a new hudson.model.Job is created and that is used for new builds. This results in a build number being used that is a duplicate of the the builds that were in the pending build queue when the reload was done. The hudson.model.Job needs to have a reload, where it will update correctly including the nextBuildNumber, to provide the hudson.model.Run objects in the pending build queue a valid object to point back to.
            danielbeck Daniel Beck made changes -
            Field Original Value New Value
            Link This issue duplicates JENKINS-27530 [ JENKINS-27530 ]
            danielbeck Daniel Beck made changes -
            Resolution Duplicate [ 3 ]
            Status Open [ 1 ] Resolved [ 5 ]
            Hide
            jglick Jesse Glick added a comment - - edited

            Jeff Miller yes that appears to be the correct analysis, that a Queue.Item.task refers to a stale Job.

            Show
            jglick Jesse Glick added a comment - - edited Jeff Miller yes that appears to be the correct analysis, that a Queue.Item.task refers to a stale Job .
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 169788 ] JNJira + In-Review [ 198682 ]

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              jeff_a_miller Jeff Miller
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: