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
meshregistry
andgo-zk
and runs in different goroutines.The
go-zk
reconnect relies onmeshregsitry
callingzk.Conn.Close
to terminate the reconnect, but there is no synchronization mechanism between the two.If
go-zk
do reconnect before theClose
call, it will cause themeshregsitry
to be triggered to reconnect again after theClose
call, which in turn will cause thezk.Conn
created by the previousmeshregsitry
reconnect to be closed and triggered to reconnect again and again.We've made two improvements for this:
meshregistry
reconnect ifgo-zk
reconnects successfully before triggeringmeshregistry
reconnect.meshregistry
reconnect creates a newzk.Conn
, we require that eachzk.Conn
can only trigger ameshregistry
reconnect once.