Potential race condition in pool initialization

Description

With asynchronous connection pool initialization (JAVA-692), we introduced the phase field to track the pool's state. Once a pool is closed, we set the phase to CLOSING in order to reject subsequent calls to borrowConnection.

The phase is also mutated during initialization:

HostConnectionPool.java

It's possible that a pool gets closed before it's fully initialized, which is why we check at line 131. But this is a check-then-act, and therefore not thread-safe: the pool could get closed between line 131 and line 137, and we would set the phase to READY on a closed pool.

This is problematic because a call to borrowConnection on a pool in such a state would succeed and recreate connections, creating a leak.

In practice this is very unlikely: the window where the pool needs to be closed is very small, as is the chance that a client will obtain a reference to the pool (whenever we close a pool it also gets removed from the session). We've not been able to produce the bug in tests. However, for the sake of correctness, we're going to address this issue.

Environment

None

Pull Requests

None

Activity

Show:
Andy Tolbert
May 19, 2015, 7:35 PM

Ran a variety of connection stress tests and could not manifest the issue with and without these fixes, though +1 on the need for the change given the small window of opportunity for a Pool to be marked in 'READY' phase after its closed and still present for a host.

Fixed

Assignee

Olivier Michallat

Reporter

Olivier Michallat

Labels

None

PM Priority

None

Reproduced in

2.0.10

Affects versions

None

Fix versions

Pull Request

None

Doc Impact

None

Size

None

External issue ID

None

External issue ID

None

Priority

Major
Configure