PoolingOptions issues

[Paul Fife]

It looks like the PoolingOptions set core/max connections methods check on every call for validity of the resulting configuration, which causes some issues when creating a new object from scratch with all values. If the core size is larger than the default max you need to call setMax first, and if the max size is smaller than the default core you need to call setCore first. This is a pain if you're trying to create a brand new PoolingObjects from scratch to pass to the Cluster.Builder's withPoolingOptions method.

A couple sensible ways to make this better seem like either providing a PoolingObjects builder or providing methods that allow setting related values (core/max) at the same time.

[Olivier Michallat]

Hi,

Yes, these setters check the invariant on every call. This makes sense because they can be called at runtime, but I'll admit that this is mildly annoying in the case you described.

I've created JAVA-662 to add setters that take both values.

--

Olivier Michallat

Driver & tools engineer, DataStax

On Mon, Feb 2, 2015 at 9:56 PM, Paul Fife <paul...@gmail.com> wrote:

It looks like the PoolingOptions set core/max connections methods check on every call for validity of the resulting configuration, which causes some issues when creating a new object from scratch with all values. If the core size is larger than the default max you need to call setMax first, and if the max size is smaller than the default core you need to call setCore first. This is a pain if you're trying to create a brand new PoolingObjects from scratch to pass to the Cluster.Builder's withPoolingOptions method.

A couple sensible ways to make this better seem like either providing a PoolingObjects builder or providing methods that allow setting related values (core/max) at the same time.

To unsubscribe from this group and stop receiving emails from it, send an email to java-driver-us...@lists.datastax.com.