JDK-8169465 : Deadlock in com.sun.jndi.ldap.pool.Connections
  • Type: Bug
  • Component: core-libs
  • Sub-Component: javax.naming
  • Affected Version: 8u92
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-11-09
  • Updated: 2018-02-08
  • Resolved: 2016-12-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9 Other
8u121Fixed 9 b150Fixed openjdk7uFixed
Description
Ordinarily when getPooledConnection() is called it will lock the connections
map (0x00000000861e8e18) and then perform a Connections.get() on an
individual Connections object. Since Connections.get() is synchronised, this
Connections object is locked.

In parallel to this the PoolCleaner thread may call cleanup() which in turn
calls Pool.expire(). This call grabs a lock to the connections map
(0x00000000861e8e18) and then attempts to run Connections.expire() on an
individual Connections object.

Unfortunately in this instance the PoolCleaner thread is grabbing the
connections map (0x00000000861e8e18) before getPooledConnection() can lock
it, but *after* our thread has locked the Connections object
(0x000000008b0c96d0) in the previous recursive set of calls.

The situation is complicated by both the recursion and the fact that we
are locking on a different Connections object than we had been
previously in the stack.