Introduce initial reconnection policy

[dkropachev]

We would want to retry on initial connection to the cluster, in case if cluster is not ready yet.

This PR introduced new InitialReconnectionPolicy option to ServerConfig, by default it is NoReconnectionPolicy, to ensure old behavior.

Closes #230

[knadh]

This is good to see! A couple of thoughts:

The ideal behaviour would be for the reconnect attempts to happen in the background or to be deferred (this could be configurable in the policy) so that NewSession() does not block. In many production scenarios, an app should be able to boot without a single DB driver blocking indefinitely, and the drive connects whenever the upstream server becomes available based on reconnection policies.

That's how Postgres, Redis etc. drivers/clients generally behave, where the client can be initialized without blocking, and the actual connection and discovery happen based on activity (Ping() or Query() etc.) or in the background. Any attempt to use the client without an underlying connection simply returns an error without panicking, which can be handled gracefully.

Thank you.

[dkropachev]

This is good to see! A couple of thoughts:

The ideal behaviour would be for the reconnect attempts to happen in the background or to be deferred (this could be configurable in the policy) so that NewSession() does not block. In many production scenarios, an app should be able to boot without a single DB driver blocking indefinitely, and the drive connects whenever the upstream server becomes available based on reconnection policies.

That's how Postgres, Redis etc. drivers/clients generally behave, where the client can be initialized without blocking, and the actual connection and discovery happen based on activity (Ping() or Query() etc.) or in the background. Any attempt to use the client without an underlying connection simply returns an error without panicking, which can be handled gracefully.

Thank you.

Thanks for taking your time reviewing it and commenting.
It is better to do that in a seperate PR, it implicate totally different way of initialization and some scenarios become invalid anymore, for example currently we are checking if dc in load balancing policy matches cluster configuration and throw an error if it is not.
Such validations are imposible until driver is actually connected.

[sylwiaszunejko]

Do we want to check the behavior with different InitialReconnectionPolicy than default? I am wondering if there is some way to test it?

[dkropachev]

Do we want to check the behavior with different InitialReconnectionPolicy than default? I am wondering if there is some way to test it?

Done, please take a look

[dkropachev]

This is good to see! A couple of thoughts:
The ideal behaviour would be for the reconnect attempts to happen in the background or to be deferred (this could be configurable in the policy) so that NewSession() does not block. In many production scenarios, an app should be able to boot without a single DB driver blocking indefinitely, and the drive connects whenever the upstream server becomes available based on reconnection policies.
That's how Postgres, Redis etc. drivers/clients generally behave, where the client can be initialized without blocking, and the actual connection and discovery happen based on activity (Ping() or Query() etc.) or in the background. Any attempt to use the client without an underlying connection simply returns an error without panicking, which can be handled gracefully.
Thank you.

Thanks for taking your time reviewing it and commenting. It is better to do that in a seperate PR, it implicate totally different way of initialization and some scenarios become invalid anymore, for example currently we are checking if dc in load balancing policy matches cluster configuration and throw an error if it is not. Such validations are imposible until driver is actually connected.

@knadh , please take a look at #234