Cluster discovery via server info

[wallyqs]

• Implements cluster auto discovery which 0.9.2 server now supports
• Bumps gem to 0.8.0 major version

[ripienaar]

Guessing a doc update is pending but with this you only tell the gem one server in a cluster and it discovers new ones and will fall over to them?

On fall over will it again discover a new set and expel ones not valid anymore? I have very long running clients - months - so for this kind of thing to make sense there must be some runtime refreshing.

[wallyqs]

Yes doc updates are pending, but it basically works as you mention. As new nodes attach to the cluster the clients puts them on the list of nodes to which it can connect as server announces them. During fail over, it will back off in case any of those servers failed previously when attempting to reconnect.

[ripienaar]

Oh so even during the normal connection as servers come and go they will be announced and the client will update its state - without having to reconnect to get a new list?

That is amazing if that's how it works. Really good thanks

[wallyqs]

Yes that is how it works, not needed to reconnect to get new list of servers as long as nodes attach to the same cluster /cc @kozlovic

[ripienaar]

Brilliant thank you. That'lol hugely simplify life

[kozlovic]

When the client library connects to a server that is already part of a cluster, it will get the list of connect URLs of all servers, and add it to its list of servers. These will be used during a reconnect.
Note that when servers come up and go in the cluster, there is no update to client (unless their listen spec has changed). So there is no URL removal with this change.
But as Wally mentioned, server URLs that are tried more than the configurable reconnect attempts are removed from the pool of server URLs, so they won't be tried more than what is configured.

[kozlovic]

When I wrote "come and go", I am talking about a server that is stopped/restarted, not new server added to the cluster. Say that you have a cluster of servers A, B and C (full mesh). If a client connects to A, it will be sent the list of B and C. Now say C is stopped, there is no update to clients. C is brought back up, there is still no update to clients. D joins the mesh, clients will be notified of this addition.

[ripienaar]

I see thanks. Live topology updates would be super handy for people who elasticly build their cluster but as is its already a good advantage - cluster members come and go on different IPs. For now I use SRV in my client code and update the record dynamically.

I realise achieving live updates is a MATS protocol change and so probably quite unlikely