-
Bug
-
Resolution: Fixed
-
Critical
A parallel-capable job was observed to be stuck in a later build just because an earlier build was still running:
"Executor #1 for ... : executing ... #6268 : waiting for Check point mail sent on ... #6266" ... java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:503) at hudson.model.Run$RunExecution$CheckpointSet.waitForCheckPoint(Run.java:1453) - locked <0x...> (a hudson.model.Run$RunExecution$CheckpointSet) at hudson.model.Run.waitForCheckpoint(Run.java:1411) at hudson.model.CheckPoint.block(CheckPoint.java:144) at hudson.tasks.MailSender.findPreviousBuildResult(MailSender.java:144) at hudson.tasks.MailSender.getMail(MailSender.java:166) at hudson.tasks.MailSender.execute(MailSender.java:100) at hudson.tasks.Mailer.perform(Mailer.java:117)
As in JENKINS-16376, this is senseless. If the earlier build is not yet done, it is better to just not report any state transition.
- is duplicated by
-
JENKINS-20305 Jobs are waiting concurrent builds to finish when mailer is active
- Resolved
- is related to
-
JENKINS-9913 Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent
- Resolved
-
JENKINS-16376 BuildStepMonitor.BUILD makes concurrent builds wait, could be changed to BuildStepMonitor.NONE?
- Resolved