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