Deadlocked queue (JENKINS-28840)

Issue

You upgraded to 1.609 through to 1.617, your instance doesn’t reply and a threads dump reports a deadlock where one of the deadlocks includes hudson.model.Queue.maintain() and the other deadlocked thread includes Executor like so:

at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
  at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
  at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
  at hudson.model.Queue._withLock(Queue.java:1205)
  at hudson.model.Queue.withLock(Queue.java:1143)
  at hudson.model.Computer.removeExecutor(Computer.java:977)
  at hudson.model.Executor.interrupt(Executor.java:187)

Environment

CloudBees Jenkins Enterprise 15.05 ( 1.609.1.1 )
Jenkins 1.609 -> 1.617

Resolution

This problem was reported as JENKINS-28840 and is fixed in Jenkins 1.618 (and should be in the LTS 1.609.3).

If you are running CloudBees Jenkins Enterprise 15.05 ( 1.609.1.1 ) please contact the CloudBees Support who will provide you a hotfix for this problem.

This article is part of our Knowledge Base and is provided for guidance-based purposes only. The solutions or workarounds described here are not officially supported by CloudBees and may not be applicable in all environments. Use at your own discretion, and test changes in a safe environment before applying them to production systems.