PoolingOptions - should they be adhered when the server support Scylla Shard Extenstions

[slivne]

When a client connect to a server supporting the Scylla Protocol Extension for Intranode Sharding the driver will open connections to each shard

A client can also setup PoolingOptions

It is not clear the interaction between the two and if PoolingOptions should be adhered or not.

One solution is to disregard PoolingOptions altogether is Intranode Sharding is available.

[haaawk]

The interaction is as follows:

1. Pooling options set core connections per host and max connections per host
2. If shard awareness is enabled then each shard gets coreConnectionsSize / shardsCount + (coreConnectionsSize % shardsCount > 0 ? 1 : 0) connections but we still try to respect max connections per host by not adding new connections when sum of shard's connections exceeds max connections per host.

Does that explain the matter enough or do you have any additional questions @slivne?

[haaawk]

@slivne ping. Would you like me to do anything with this or can we close the issue?

[kbr-]

Documentation should be updated (https://github.com/scylladb/java-driver/tree/latest/manual/pooling#configuring-the-connection-pool), we can't tell users to read the driver's code