You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@curator.apache.org by Jordan Zimmerman <jo...@jordanzimmerman.com> on 2020/05/01 16:17:02 UTC
Re: CURATOR WITH MULTIPLE ZK SERVERS
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.camarero@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
>
Re: CURATOR WITH MULTIPLE ZK SERVERS
Posted by "evaristo.camarero@yahoo.es" <ev...@yahoo.es>.
Thanks Jordan. I Will submit the pr with builder changes
Enviado desde Yahoo Mail con Android
El dom., may. 3, 2020 a 20:52, Jordan Zimmerman<jo...@jordanzimmerman.com> escribió: We don't need a PR for a custom ensemble provider. I think the change in the builder is still needed. If you're going to just ignore the EnsembleTracker it's wasteful to run it. It should be disabled.
-JZ
On May 3, 2020, at 1:44 PM, evaristo.camarero@yahoo.es wrote:
Works fine in my use case andconnecString changes are ignored that is what I am looking after.
I have not seen any problem in myapp.
There are other CuratorFrameworkmethods like config(), reconfig() and I am not sure if thisImmutableEnsembleProvider could have any side effect there and potentiallyaffect any Curator recipe. I understand from your previous answer that you dono think that is the case.
A possible solution for CURATOR-558is to include an ImmutableEnsembleProvider. That avoids adding extra methods tothe CuratorFrameworkFactory.Builder. What do you think is best? Do you still believe that is worthy to extend the builder?
Thanks,
/Evaristo
En domingo, 3 de mayo de 2020 20:09:04 CEST, Jordan Zimmerman <jo...@jordanzimmerman.com> escribió:
Try it and see. Why would there be side effects?
-Jordan
On May 3, 2020, at 12:42 PM, evaristo.camarero@yahoo.es wrote:
Hi again,
I am looking for a possible workaround in myapplication until there is new Curator release with Curator 558
I am just curious aboutthe side effects of using a custom EnsembleProvider that basically ignores newconnectStrings passed via setConnectString... I guess connecString will not be changed, but I am not sureof possible side effects on Curator.
public classCustomEnsembleProvider implements EnsembleProvider
{
privatefinal String connectionString;
/**
*The connection string to use
*
*@param connectionString connection string
*/
public CustomEnsembleProvider (String connectionString)
{
this.connecitonString = Objects.requiernonNull(connectionString);
}
@Override
publicvoid start() throws Exception
{
// DO nothing
}
@Override
publicvoid close() throws IOException
{
// DO nothing
}
@Override
publicvoid setConnectionString(String connectionString)
{
// DO nothing
}
@Override
publicString getConnectionString()
{
return connectionString;
}
@Override
publicboolean updateServerListEnabled()
{
return false;
}
}
Thanks in advance,
/Evaristo
En viernes, 1 de mayo de 2020 19:33:15 CEST, evaristo.camarero@yahoo.es <ev...@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 <jo...@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.camarero@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 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 <jo...@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.camarero@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
Re: CURATOR WITH MULTIPLE ZK SERVERS
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
We don't need a PR for a custom ensemble provider. I think the change in the builder is still needed. If you're going to just ignore the EnsembleTracker it's wasteful to run it. It should be disabled.
-JZ
> On May 3, 2020, at 1:44 PM, evaristo.camarero@yahoo.es wrote:
>
>
> Works fine in my use case and connecString changes are ignored that is what I am looking after.
>
> I have not seen any problem in my app.
>
> There are other CuratorFramework methods like config(), reconfig() and I am not sure if this ImmutableEnsembleProvider could have any side effect there and potentially affect any Curator recipe. I understand from your previous answer that you do no think that is the case.
>
> A possible solution for CURATOR-558 is to include an ImmutableEnsembleProvider. That avoids adding extra methods to the CuratorFrameworkFactory.Builder. What do you think is best? Do you still believe that is worthy to extend the builder?
>
> Thanks,
>
> /Evaristo
>
>
> En domingo, 3 de mayo de 2020 20:09:04 CEST, Jordan Zimmerman <jo...@jordanzimmerman.com> escribió:
>
>
> Try it and see. Why would there be side effects?
>
> -Jordan
>
>> On May 3, 2020, at 12:42 PM, evaristo.camarero@yahoo.es <ma...@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.camarero@yahoo.es <ma...@yahoo.es> <evaristo.camarero@yahoo.es <ma...@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 <jordan@jordanzimmerman.com <ma...@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.camarero@yahoo.es <ma...@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 <jordan@jordanzimmerman.com <ma...@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.camarero@yahoo.es <ma...@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
>>>>
>>>
>>
>
Re: CURATOR WITH MULTIPLE ZK SERVERS
Posted by "evaristo.camarero@yahoo.es" <ev...@yahoo.es>.
Works fine in my use case andconnecString changes are ignored that is what I am looking after.
I have not seen any problem in myapp.
There are other CuratorFrameworkmethods like config(), reconfig() and I am not sure if thisImmutableEnsembleProvider could have any side effect there and potentiallyaffect any Curator recipe. I understand from your previous answer that you dono think that is the case.
A possible solution for CURATOR-558is to include an ImmutableEnsembleProvider. That avoids adding extra methods tothe CuratorFrameworkFactory.Builder. What do you think is best? Do you still believe that is worthy to extend the builder?
Thanks,
/Evaristo
En domingo, 3 de mayo de 2020 20:09:04 CEST, Jordan Zimmerman <jo...@jordanzimmerman.com> escribió:
Try it and see. Why would there be side effects?
-Jordan
On May 3, 2020, at 12:42 PM, evaristo.camarero@yahoo.es wrote:
Hi again,
I am looking for a possible workaround in myapplication until there is new Curator release with Curator 558
I am just curious aboutthe side effects of using a custom EnsembleProvider that basically ignores newconnectStrings passed via setConnectString... I guess connecString will not be changed, but I am not sureof possible side effects on Curator.
public classCustomEnsembleProvider implements EnsembleProvider
{
privatefinal String connectionString;
/**
*The connection string to use
*
*@param connectionString connection string
*/
public CustomEnsembleProvider (String connectionString)
{
this.connecitonString = Objects.requiernonNull(connectionString);
}
@Override
publicvoid start() throws Exception
{
// DO nothing
}
@Override
publicvoid close() throws IOException
{
// DO nothing
}
@Override
publicvoid setConnectionString(String connectionString)
{
// DO nothing
}
@Override
publicString getConnectionString()
{
return connectionString;
}
@Override
publicboolean updateServerListEnabled()
{
return false;
}
}
Thanks in advance,
/Evaristo
En viernes, 1 de mayo de 2020 19:33:15 CEST, evaristo.camarero@yahoo.es <ev...@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 <jo...@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.camarero@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 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 <jo...@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.camarero@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
Re: CURATOR WITH MULTIPLE ZK SERVERS
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Try it and see. Why would there be side effects?
-Jordan
> On May 3, 2020, at 12:42 PM, evaristo.camarero@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.camarero@yahoo.es <ev...@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 <jo...@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.camarero@yahoo.es <ma...@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 <jordan@jordanzimmerman.com <ma...@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.camarero@yahoo.es <ma...@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
>>>
>>
>
Re: CURATOR WITH MULTIPLE ZK SERVERS
Posted by "evaristo.camarero@yahoo.es" <ev...@yahoo.es>.
Hi again,
I am looking for a possible workaround in myapplication until there is new Curator release with Curator 558
I am just curious aboutthe side effects of using a custom EnsembleProvider that basically ignores newconnectStrings passed via setConnectString... I guess connecString will not be changed, but I am not sureof possible side effects on Curator.
public classCustomEnsembleProvider implements EnsembleProvider
{
privatefinal String connectionString;
/**
*The connection string to use
*
*@param connectionString connection string
*/
public CustomEnsembleProvider (String connectionString)
{
this.connecitonString = Objects.requiernonNull(connectionString);
}
@Override
publicvoid start() throws Exception
{
// DO nothing
}
@Override
publicvoid close() throws IOException
{
// DO nothing
}
@Override
publicvoid setConnectionString(String connectionString)
{
// DO nothing
}
@Override
publicString getConnectionString()
{
return connectionString;
}
@Override
publicboolean updateServerListEnabled()
{
return false;
}
}
Thanks in advance,
/Evaristo
En viernes, 1 de mayo de 2020 19:33:15 CEST, evaristo.camarero@yahoo.es <ev...@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 <jo...@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.camarero@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 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 <jo...@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.camarero@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
Re: CURATOR WITH MULTIPLE ZK SERVERS
Posted by "evaristo.camarero@yahoo.es" <ev...@yahoo.es>.
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 <jo...@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.camarero@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 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 <jo...@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.camarero@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
Re: CURATOR WITH MULTIPLE ZK SERVERS
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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.camarero@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 <jo...@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.camarero@yahoo.es <ma...@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
>>
>
Re: CURATOR WITH MULTIPLE ZK SERVERS
Posted by "evaristo.camarero@yahoo.es" <ev...@yahoo.es>.
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 <jo...@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.camarero@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