Sorry. I used the wrong list
En jueves, 30 de abril de 2020 16:49:18 CEST, [email protected]
<[email protected]> escribió:
Hi there,
We have an app that is connected to 2 different ZK clusters (one ZK in the same
data center, a remote ZK cluster in a remote data center). In the same JVM, we
instantiate 2 CuratorFramework instances (once per ZK cluster)
We were using ZK clusters with zk 3.4.10
And Curator clients with Curator 4.3.0 + Zk 3.4.10
Everything working fine.
Now we are upgrading zk servers to 3.5.6 and making tests with this
combination:
ZK clusters are ZK 3.5.6
And our Curator Clients are Curator 4.3.0 + ZK 3.4.10 (working in compatibility
mode)
There is a use case that is failing and probably is related with ZK dynamic
reconfiguration capabilities supported in ZK 3.5 and would like to understand
better how Curator handles this.
The issue appears when our application can connect to the local cluster, but
connectivity with remote cluster is broken.
At this point session the CuratorFramework session with remote cluster is
expired (SUSPENDED, LOST...), and we can observe that curator calculates again
the connectString
: "Connection string changed to: xxxx"
, ignoring the initial connect string provided when CuratorFramework instance
was created. This new connectString is not valid for the remote cluster; the
reason is that our routing is a bit complex, and we connect to remote cluster
via a Virtual IP (and this what we use when connecting to remote zk cluster
cluster) provided by a Load balancer (In this case is a Kubernetes ingress
gateway)
The original connect string was: 10.10.10.10: 2181 (Actually is Virtual IP to
connect with remote cluster), but the new negotiated connect string is
different because reflects the remote cluster topology internals with multiple
servers
I saw that CuratorFrameworkFactory builder allows to set the EnsembleProvider
when creating CF instances, and I am not 100% sure if using a
FixedEnsembleProvider with updateServerListEnabled to false could be enough to
fix the issue. So, I would appreciate any information about how
CuratorFramework 4.3 handles connectString changes, and a possible way forward
to limit that connectString is changed dynamically.
Thanks in advance,
/Evaristo
