Refactor HostConnectionPool to a non-blocking implementation

Description

Currently, our connection pool is implemented with a condition queue (wait/notify) and blocks the calling thread when you try to borrow the connection with a timeout. The recommended workaround to avoid blocking is to set PoolingOptions.poolTimeoutMillis to 0.

Refactor the pool to avoid blocking.
borrowConnection should return a Future<Connection>. Instead of using a timeout, we should probably enqueue callers and expose a maximum queue size.

This will also allow us to chain the USE call when we need to change the keyspace on the connection, instead of blocking on it.

Environment

None

Pull Requests

None

Activity

Show:
Andy Tolbert
September 18, 2017, 2:22 PM

If the pool is busy and can't accept new queries, queries should be just queued and wait for their turn, and the queue size should be controllable in query options (or other config), with a rather large default (the only limitation is really available memory size). Is it possible to do that now with settings?

That can be controlled via PoolingOptions.setMaxQueueSize. The default queue size is rather small (256). Entries in the queue will be timed out via PoolingOptions.setPoolTimeoutMillis so you may need to adjust that beyond the default as well (it defaults to 5 seconds).

Piotr Kołaczkowski
September 18, 2017, 7:47 AM
Edited

We get busy pool exceptions due to this.

If we schedule many async queries at once, the returned Futures fail with BusyPoolException. We have to retry them, or put low limits on the number of async queries submitted in parallel / or wait-retry on the client. I mean, it is not a huge problem for us, because we can deal with it, but I guess other users of the driver will be running into this.

If the pool is busy and can't accept new queries, queries should be just queued and wait for their turn, and the queue size should be controllable in query options (or other config), with a rather large default (the only limitation is really available memory size). Is it possible to do that now with settings?

Olivier Michallat
August 27, 2015, 8:37 AM

Good point, I forgot to mention that in the doc for JAVA-822.

Andy Tolbert
August 26, 2015, 9:46 PM

This will also be useful because borrowConnection calls setKeyspace which is currently blocking if the keyspace for the Connection does not match the keyspace expected for the Session. I.E. if someone does a 'USE <keyspace>' after connecting the session.

Fixed

Assignee

Unassigned

Reporter

Olivier Michallat

Labels

None

PM Priority

None

Affects versions

Fix versions

Pull Request

None

Doc Impact

None

Size

None

External issue ID

None

External issue ID

None

Priority

Major