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.)
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.