-
Bug
-
Resolution: Fixed
-
Major
-
1.466.x
"Handling POST /job/.../ajaxBuildQueue : ... java.lang.Thread.State: BLOCKED (on object monitor) at hudson.model.ResourceController.getBlockingActivity(ResourceController.java:129) - waiting to lock <0x00000000c11cf910> (a hudson.model.Queue) at hudson.model.Queue$BlockedItem.getCauseOfBlockage(Queue.java:1490) at hudson.model.Queue$Item.getWhy(Queue.java:1309) at sun.reflect.GeneratedMethodAccessor681.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601)
The cause of blockage is just informational; should not wait for the Queue lock just for this.
- is related to
-
JENKINS-16468 Lock contention in executor queue
-
- Resolved
-
[JENKINS-16833] Queue$BlockedItem.getCauseOfBlockage waiting for lock on Queue
Link |
New:
This issue is related to |
Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
Assignee | New: Jesse Glick [ jglick ] |
Resolution | New: Fixed [ 1 ] | |
Status | Original: In Progress [ 3 ] | New: Resolved [ 5 ] |
Labels | Original: performance | New: 1.480.4-candidate performance |
Labels | Original: 1.480.4-candidate performance | New: lts-candidate performance |
It is possible that a fix of
JENKINS-16831would resolve this, since it appeared to be the call to Queue.getItems which was holding the lock for too long. Nonetheless it would be better to avoid even trying to acquire this monitor from an HTTP thread, so: pull #712