Summary

The spec requires the WaitQueue to be fair. Fairness is usually used to improve tail latencies at the cost of degraded throughput. In case of the Java driver, this requirement combined with the requirement to clear the WaitQueue when pausing the pool has too much of a negative impact on the throughput of the connection pool (the maximum number of checkout&checkin cycles per unit of time): JAVA-4452, JAVA-5680. While the Java driver probably could solve the issue by redesigning and reimplementing the connection pool in a way similar to how it's done in the Rust driver, the game does not seem worth the candle.

Motivation

Who is the affected end user?

Driver maintainers.

How does this affect the end user?

It complicates the implementation.

How likely is it that this problem or use case will occur?

N/A

If the problem does occur, what are the consequences and how severe are they?

May negatively affect throughput beyond what is tolerable or complicate the design.

Is this issue urgent?

It is not urgent, but it does prevent the Java driver from having a decent throughput (provided, that we don't want to redesign/reimplement the pool in the Java driver).

Is this ticket required by a downstream team?

Yes, it makes the Java driver the bottleneck in server performance benchmarks: JAVA-5680.

Is this ticket only for tests?

No.

Acceptance Criteria

N/A