-
Bug
-
Resolution: Duplicate
-
Major
If there is a job that gets very rapidly scheduled, since a Run.id currently must be unique to the second, a lot of the time the Queue will be locked:
... waiting on condition [...] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at hudson.model.AbstractProject.newBuild(AbstractProject.java:1121) - locked <...> (a hudson.model.FreeStyleProject) at hudson.model.AbstractProject.createExecutable(AbstractProject.java:1349) at hudson.model.AbstractProject.createExecutable(AbstractProject.java:156) at hudson.model.Executor.run(Executor.java:211) - locked <...> (a hudson.model.Queue)
which can prevent other things from happening, such as routine queue maintenance, or even rendering of the queue widget (which expects a fresh snapshot every second):
"Handling ..." ... waiting for monitor entry [...] java.lang.Thread.State: BLOCKED (on object monitor) at hudson.model.Queue.getItems(Queue.java:685) - waiting to lock <...> (a hudson.model.Queue) at hudson.model.Queue$CachedItemList.get(Queue.java:217) at hudson.model.Queue.getApproximateItemsQuickly(Queue.java:715) at hudson.model.View.getApproximateQueueItemsQuickly(View.java:483)
(This also artificially slows down some functional tests.)
- is related to
-
JENKINS-19977 Build records get confused by timezone changes
- Resolved
-
JENKINS-24380 Use build numbers as IDs
- Resolved
- links to