The reconnect logic is written in both the meshregistry and go-zk and runs in different goroutines.
The go-zk reconnect relies on meshregsitry calling zk.Conn.Close to terminate the reconnect, but there is no synchronization mechanism between the two.
If go-zk do reconnect before the Close call, it will cause the meshregsitry to be triggered to reconnect again after the Close call, which in turn will cause the zk.Conn created by the previous meshregsitry reconnect to be closed and triggered to reconnect again and again.
We've made two improvements for this:
Skip triggering meshregistry reconnect if go-zk reconnects successfully before triggering meshregistry reconnect.
Since meshregistry reconnect creates a new zk.Conn, we require that each zk.Conn can only trigger a meshregistry reconnect once.
The reconnect logic is written in both the
meshregistryandgo-zkand runs in different goroutines.The
go-zkreconnect relies onmeshregsitrycallingzk.Conn.Closeto terminate the reconnect, but there is no synchronization mechanism between the two.If
go-zkdo reconnect before theClosecall, it will cause themeshregsitryto be triggered to reconnect again after theClosecall, which in turn will cause thezk.Conncreated by the previousmeshregsitryreconnect to be closed and triggered to reconnect again and again.We've made two improvements for this:
meshregistryreconnect ifgo-zkreconnects successfully before triggeringmeshregistryreconnect.meshregistryreconnect creates a newzk.Conn, we require that eachzk.Conncan only trigger ameshregistryreconnect once.