Thx Jordan for the fast answer.
I see 2 options here:
1.- Add a new option in CuratorFrameworkFactory.Builder -> for instance
.skipEnsembleTracking. If the option is present make ensembleTracker null in
CuratorFrameworkImpl2.- Other option is to modify EnsembleTracker, and if the
EnsembleProvider is a FixedEnsembleProvider with updatSErverList set to false,
ignore configuration events.
What do you think is better?- Personally option 1 looks to me a bit strange: If
Builder allows to use a FixedEnsebleProvider with updatServers set to false,
but servers list will be really updated unless you are using the new option
that is a bit misleading.- Option 2 has a more clear API in my view, if
FixedEnsembleProvider is used with updateServerList set to false, then
EnsembleTracker can ignore updating the connecstring.
Regards,
/Evaristo
En viernes, 1 de mayo de 2020 18:17:17 CEST, Jordan Zimmerman
<jor...@jordanzimmerman.com> escribió:
I think this might be a bug or maybe an oversight. It looks like the
EnsembleTracker gets enabled regardless of the mode that Curator is in: see
CuratorFrameworkImpl's constructor where it allocates an EnsembleTracker. You
could open a PR that makes this optional.
-Jordan
On Apr 30, 2020, at 10:00 AM, evaristo.camar...@yahoo.es wrote:
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
