Try it and see. Why would there be side effects?
-Jordan
> On May 3, 2020, at 12:42 PM, evaristo.camar...@yahoo.es wrote:
>
> Hi again,
> I am looking for a possible workaround in my application until there is new
> Curator release with Curator 558
> I am just curious about the side effects of using a custom EnsembleProvider
> that basically ignores new connectStrings passed via setConnectString... I
> guess connecString will not be changed, but I am not sure of possible side
> effects on Curator.
>
> public class CustomEnsembleProvider implements EnsembleProvider
> {
> private final String connectionString;
> /**
> * The connection string to use
> *
> * @param connectionString connection string
> */
> public CustomEnsembleProvider (String connectionString)
> {
> this.connecitonString = Objects.requiernonNull(connectionString);
> }
>
> @Override
> public void start() throws Exception
> {
> // DO nothing
> }
>
> @Override
> public void close() throws IOException
> {
> // DO nothing
> }
>
> @Override
> public void setConnectionString(String connectionString)
> {
> // DO nothing
> }
>
> @Override
> public String getConnectionString()
> {
> return connectionString;
> }
>
> @Override
> public boolean updateServerListEnabled()
> {
> return false;
> }
> }
> Thanks in advance,
> /Evaristo
>
>
> En viernes, 1 de mayo de 2020 19:33:15 CEST, evaristo.camar...@yahoo.es
> <evaristo.camar...@yahoo.es> escribió:
>
>
> Thx Jordan. I will a open JIRA ticket with a PR as discussed
> En viernes, 1 de mayo de 2020 19:18:25 CEST, Jordan Zimmerman
> <jor...@jordanzimmerman.com> escribió:
>
>
> For backward compatibility I think Option 1 is the only option. We can't know
> who's reliant on the current behavior.
>
> -JZ
>
>> On May 1, 2020, at 12:13 PM, evaristo.camar...@yahoo.es
>> <mailto:evaristo.camar...@yahoo.es> wrote:
>>
>> 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
>> CuratorFrameworkImpl
>> 2.- 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 <mailto: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
>>> <mailto: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
>>>
>>
>
