You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@curator.apache.org by Ioannis Canellos <io...@gmail.com> on 2013/04/26 21:24:57 UTC
Ensemble Provider best practices
Hi,
I have a case where the ensemble can change (by adding/removing zk servers)
and I wanted to find the best approach on reconfiguring the curator
framework.
It seemed like a good idea to implement my custom ensemble provider, which
would receive updates with the modified connectionString.
This works fine, if I mark the zookeeper client as lost (so that the
framework can pick the updated connection string from the EnsembleProvider).
The problem is that after that the ConnectionStateListeners are not
receiving any events for CONNECTED/RECONNECTED etc.
Is this expected?
Is there any other approach for changing the connection string, without
recreating the CuratorFramework?
Thanks in advance.
Re: PersistentEphemeralNode recipe
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Sorry for the delay. I'll look at this as soon as I can.
-JZ
On May 23, 2013, at 12:29 AM, Evaristo José Camarero <ev...@yahoo.es> wrote:
>
> Hi there,
>
> I attached an implementation for this issue and some unit testing. Any comments on this?
>
> Evaristo
>
> De: Jordan Zimmerman <jo...@jordanzimmerman.com>
> Para: Evaristo José Camarero <ev...@yahoo.es>
> CC: "user@curator.incubator.apache.org" <us...@curator.incubator.apache.org>
> Enviado: Lunes 13 de Mayo de 2013 7:17
> Asunto: Re: PersistentEphemeralNode recipe
>
> I've created a Jira for this - https://issues.apache.org/jira/browse/CURATOR-25
>
> Please attach implementations to that issue.
>
> -JZ
>
> On May 10, 2013, at 2:24 PM, Evaristo José Camarero <ev...@yahoo.es> wrote:
>
>> Hi there,
>>
>> I attach the files with the proposal for the PersistentEphemeralNode evolved from your original code (https://gist.github.com/4047093).
>>
>> The proposal adds the possibility to replace the data in the Persistent Ephemeral Node during its lifecycle.
>>
>> I have also added a coupled of test cases.
>>
>> Please provide me some feedback (both proposal and test cases), and I can further develop the code.
>>
>> Regards,
>>
>> Evaristo
>>
>> De: Jordan Zimmerman <jo...@jordanzimmerman.com>
>> Para: user@curator.incubator.apache.org; Evaristo José Camarero <ev...@yahoo.es>
>> Enviado: Sábado 4 de Mayo de 2013 18:32
>> Asunto: Re: PersistentEphemeralNode recipe
>>
>> I'd really like to see this recipe available. So, please go ahead.
>>
>> -JZ
>>
>> On May 4, 2013, at 1:01 AM, Evaristo José Camarero <ev...@yahoo.es> wrote:
>>
>>> Hi there,
>>>
>>> Some months ago there was a suggestion to implement Curator recipe to maintain an epehemeral node after session / connection problems (https://github.com/Netflix/curator/pull/201)
>>>
>>> This is a common use case in our application and I could help to properly test the current implementation proposed by Jordan (https://gist.github.com/4047093), in order to add the recipe to the Apache Curator distribution
>>>
>>> Something I am missing in the proposed implementation is the ability to change the reported data in the ephemeral node during the ephemeral node life cycle.
>>>
>>> Let me know if you believe is an interesting idea to introduce this recipe in the Apache Curator distribution.
>>>
>>> Regards,
>>>
>>> Evaristo
>>
>>
>>
>> <TestPersistentEphemeralNode.java><PersistentEphemeralNode.java>
>
>
>
Re: PersistentEphemeralNode recipe
Posted by Evaristo José Camarero <ev...@yahoo.es>.
Hi there,
I attached an implementation for this issue and some unit testing. Any comments on this?
Evaristo
________________________________
De: Jordan Zimmerman <jo...@jordanzimmerman.com>
Para: Evaristo José Camarero <ev...@yahoo.es>
CC: "user@curator.incubator.apache.org" <us...@curator.incubator.apache.org>
Enviado: Lunes 13 de Mayo de 2013 7:17
Asunto: Re: PersistentEphemeralNode recipe
I've created a Jira for this - https://issues.apache.org/jira/browse/CURATOR-25
Please attach implementations to that issue.
-JZ
On May 10, 2013, at 2:24 PM, Evaristo José Camarero <ev...@yahoo.es> wrote:
Hi there,
>
>
>I attach the files with the proposal for the PersistentEphemeralNode evolved from your original code (https://gist.github.com/4047093).
>
>
>
>The proposal adds the possibility to replace the data in the Persistent Ephemeral Node during its lifecycle.
>
>
>I have also added a coupled of test cases.
>
>
>Please provide me some feedback (both proposal and test cases), and I can further develop the code.
>
>
>Regards,
>
>
>Evaristo
>
>
>
>________________________________
> De: Jordan Zimmerman <jo...@jordanzimmerman.com>
>Para: user@curator.incubator.apache.org; Evaristo José Camarero <ev...@yahoo.es>
>Enviado: Sábado 4 de Mayo de 2013 18:32
>Asunto: Re: PersistentEphemeralNode recipe
>
>
>
>I'd really like to see this recipe available. So, please go ahead.
>
>
>-JZ
>
>
>On May 4, 2013, at 1:01 AM, Evaristo José Camarero <ev...@yahoo.es> wrote:
>
>Hi there,
>>
>>
>>Some months ago there was a suggestion to implement Curator recipe to maintain an epehemeral node after session / connection problems (https://github.com/Netflix/curator/pull/201)
>>
>>
>>This is a common use case in our application and I could help to properly test the current implementation proposed by Jordan (https://gist.github.com/4047093), in order to add the recipe to the Apache Curator distribution
>>
>>
>>Something I am missing in the proposed implementation is the ability to change the reported data in the ephemeral node during the ephemeral node life cycle.
>>
>>
>>Let me know if you believe is an interesting idea to introduce this recipe in the Apache Curator distribution.
>>
>>
>>Regards,
>>
>>
>>Evaristo
>
>
><TestPersistentEphemeralNode.java><PersistentEphemeralNode.java>
Re: PersistentEphemeralNode recipe
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
I've created a Jira for this - https://issues.apache.org/jira/browse/CURATOR-25
Please attach implementations to that issue.
-JZ
On May 10, 2013, at 2:24 PM, Evaristo José Camarero <ev...@yahoo.es> wrote:
> Hi there,
>
> I attach the files with the proposal for the PersistentEphemeralNode evolved from your original code (https://gist.github.com/4047093).
>
> The proposal adds the possibility to replace the data in the Persistent Ephemeral Node during its lifecycle.
>
> I have also added a coupled of test cases.
>
> Please provide me some feedback (both proposal and test cases), and I can further develop the code.
>
> Regards,
>
> Evaristo
>
> De: Jordan Zimmerman <jo...@jordanzimmerman.com>
> Para: user@curator.incubator.apache.org; Evaristo José Camarero <ev...@yahoo.es>
> Enviado: Sábado 4 de Mayo de 2013 18:32
> Asunto: Re: PersistentEphemeralNode recipe
>
> I'd really like to see this recipe available. So, please go ahead.
>
> -JZ
>
> On May 4, 2013, at 1:01 AM, Evaristo José Camarero <ev...@yahoo.es> wrote:
>
>> Hi there,
>>
>> Some months ago there was a suggestion to implement Curator recipe to maintain an epehemeral node after session / connection problems (https://github.com/Netflix/curator/pull/201)
>>
>> This is a common use case in our application and I could help to properly test the current implementation proposed by Jordan (https://gist.github.com/4047093), in order to add the recipe to the Apache Curator distribution
>>
>> Something I am missing in the proposed implementation is the ability to change the reported data in the ephemeral node during the ephemeral node life cycle.
>>
>> Let me know if you believe is an interesting idea to introduce this recipe in the Apache Curator distribution.
>>
>> Regards,
>>
>> Evaristo
>
>
>
> <TestPersistentEphemeralNode.java><PersistentEphemeralNode.java>
Re: PersistentEphemeralNode recipe
Posted by Evaristo José Camarero <ev...@yahoo.es>.
Hi there,
I attach the files with the proposal for the PersistentEphemeralNode evolved from your original code (https://gist.github.com/4047093).
The proposal adds the possibility to replace the data in the Persistent Ephemeral Node during its lifecycle.
I have also added a coupled of test cases.
Please provide me some feedback (both proposal and test cases), and I can further develop the code.
Regards,
Evaristo
________________________________
De: Jordan Zimmerman <jo...@jordanzimmerman.com>
Para: user@curator.incubator.apache.org; Evaristo José Camarero <ev...@yahoo.es>
Enviado: Sábado 4 de Mayo de 2013 18:32
Asunto: Re: PersistentEphemeralNode recipe
I'd really like to see this recipe available. So, please go ahead.
-JZ
On May 4, 2013, at 1:01 AM, Evaristo José Camarero <ev...@yahoo.es> wrote:
Hi there,
>
>
>Some months ago there was a suggestion to implement Curator recipe to maintain an epehemeral node after session / connection problems (https://github.com/Netflix/curator/pull/201)
>
>
>This is a common use case in our application and I could help to properly test the current implementation proposed by Jordan (https://gist.github.com/4047093), in order to add the recipe to the Apache Curator distribution
>
>
>Something I am missing in the proposed implementation is the ability to change the reported data in the ephemeral node during the ephemeral node life cycle.
>
>
>Let me know if you believe is an interesting idea to introduce this recipe in the Apache Curator distribution.
>
>
>Regards,
>
>
>Evaristo
Re: PersistentEphemeralNode recipe
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
I'd really like to see this recipe available. So, please go ahead.
-JZ
On May 4, 2013, at 1:01 AM, Evaristo José Camarero <ev...@yahoo.es> wrote:
> Hi there,
>
> Some months ago there was a suggestion to implement Curator recipe to maintain an epehemeral node after session / connection problems (https://github.com/Netflix/curator/pull/201)
>
> This is a common use case in our application and I could help to properly test the current implementation proposed by Jordan (https://gist.github.com/4047093), in order to add the recipe to the Apache Curator distribution
>
> Something I am missing in the proposed implementation is the ability to change the reported data in the ephemeral node during the ephemeral node life cycle.
>
> Let me know if you believe is an interesting idea to introduce this recipe in the Apache Curator distribution.
>
> Regards,
>
> Evaristo
PersistentEphemeralNode recipe
Posted by Evaristo José Camarero <ev...@yahoo.es>.
Hi there,
Some months ago there was a suggestion to implement Curator recipe to maintain an epehemeral node after session / connection problems (https://github.com/Netflix/curator/pull/201)
This is a common use case in our application and I could help to properly test the current implementation proposed by Jordan (https://gist.github.com/4047093), in order to add the recipe to the Apache Curator distribution
Something I am missing in the proposed implementation is the ability to change the reported data in the ephemeral node during the ephemeral node life cycle.
Let me know if you believe is an interesting idea to introduce this recipe in the Apache Curator distribution.
Regards,
Evaristo
Re: Ensemble Provider best practices
Posted by Ioannis Canellos <io...@gmail.com>.
After digging more into the problem, I see that the ConnectionStateManager
will propagate the LOST event into the ZooKeeperClient but I fail to see
how it could work the other way around.
Also for that particular use case, I can't restart the framework as it
would wipe the listeners.
What I tried locally and did work for me, was to add a reset() method in
the CuratorFramework that stops/starts the client without restarting the
connection manager (preserving this way the listeners) and propagates
manually a LOST event.
However, I am not sure if this could be a generally accepted solution or
just a workaround the problem.
On Mon, Apr 29, 2013 at 6:36 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> There is a bug either in Curator or ZooKeeper (I believe it's ZK) that
> causes the connection to hang and never reset. I'm working on a solution
> (it will be in the Apache version of Curator). So, yes, use
> EnsembleProvider.
>
> On Apr 26, 2013, at 12:24 PM, Ioannis Canellos <io...@gmail.com> wrote:
>
> > Hi,
> >
> > I have a case where the ensemble can change (by adding/removing zk
> servers) and I wanted to find the best approach on reconfiguring the
> curator framework.
> > It seemed like a good idea to implement my custom ensemble provider,
> which would receive updates with the modified connectionString.
> >
> > This works fine, if I mark the zookeeper client as lost (so that the
> framework can pick the updated connection string from the EnsembleProvider).
> > The problem is that after that the ConnectionStateListeners are not
> receiving any events for CONNECTED/RECONNECTED etc.
> >
> > Is this expected?
> >
> > Is there any other approach for changing the connection string, without
> recreating the CuratorFramework?
> >
> > Thanks in advance.
> >
>
>
--
*Ioannis Canellos*
*
**
Blog: http://iocanel.blogspot.com
**
Twitter: iocanel
*
Re: Ensemble Provider best practices
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
There is a bug either in Curator or ZooKeeper (I believe it's ZK) that causes the connection to hang and never reset. I'm working on a solution (it will be in the Apache version of Curator). So, yes, use EnsembleProvider.
On Apr 26, 2013, at 12:24 PM, Ioannis Canellos <io...@gmail.com> wrote:
> Hi,
>
> I have a case where the ensemble can change (by adding/removing zk servers) and I wanted to find the best approach on reconfiguring the curator framework.
> It seemed like a good idea to implement my custom ensemble provider, which would receive updates with the modified connectionString.
>
> This works fine, if I mark the zookeeper client as lost (so that the framework can pick the updated connection string from the EnsembleProvider).
> The problem is that after that the ConnectionStateListeners are not receiving any events for CONNECTED/RECONNECTED etc.
>
> Is this expected?
>
> Is there any other approach for changing the connection string, without recreating the CuratorFramework?
>
> Thanks in advance.
>