Initial connection vs. reconnections

[knadh]

Hi there.

gocql.NewSession() returns an error if the target cluster is unreachable for any reason. However, if it succeeds and there is a disconnection or unavailability at a later point, ReconnectInterval and ReconnectionPolicy attempts reconnections in the background gracefully.

In production, this means that if the target cluster is unavailable for any reason during an app's boot, it will fail to start outright (unless it builds its own retry/reconnect abstractions). Post successful boot, any disconnections can be handled gracefully thanks to the reconnect behaviour. Is there any way to get around the initialization being a stop-the-world bottleneck? Can it not hook into the existing reconnect behaviour?

Thank you.

[sylwiaszunejko]

Please specify gocql and scylla version, and please paste the error you are getting when the target cluster is unreachable.

[knadh]

github.com/scylladb/gocqlx/v3 v3.0.0
github.com/scylladb/gocql v.14.3

package main

import (
	"fmt"

	"github.com/gocql/gocql"
	"github.com/scylladb/gocqlx/v3"
)

func main() {
	cluster := gocql.NewCluster("127.0.0.1")

	session, err := gocqlx.WrapSession(cluster.CreateSession())
	if err != nil {
		panic(err)
	}

	fmt.Println(session)
}

Initialization fails with the following error if the cluster is unavailable with no recourse for re-connection. If the cluster fails after initialization, then re-connection attempts kick in and work gracefully.

gocql: unable to create session: unable to discover protocol version: dial tcp 127.0.0.1:9042: connect: connection refused

I just realised, I should've opened this issue on https://github.com/scylladb/gocql - My bad. @sylwiaszunejko, I can close this and re-open on the driver's repo.

[sylwiaszunejko]

I've transferred it to the right repo

[mykaul]

I've transferred it to the right repo

I wonder if it's not an issue we have in other drivers as well.

[dkropachev]

Reconnection policy is being introduced at #231, part regarging doing Session.Init later or in parallel is goign to be handled at #234