-
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
The only apparent solution is to switch to an ID format that can encode milliseconds. This could also be made to use UTC rather than local time, solving
JENKINS-19977.