curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: Persistent Ephemeral Node
Date Wed, 14 Oct 2015 23:05:06 GMT
I guess you could work it out based on the ExponentialBackoffRetry
algorithm, but it seems pretty ugly. Is it possible for you to instead just
start up a new instance of the application immediately, and then if your
crashed / seperated application comes back online, it can check if the
ephemeral node is already present and if it is just shutdown?

That would seem much less error prone.

On Thu, Oct 15, 2015 at 9:59 AM, Vikrant Singh <vikrant.subscribe@gmail.com>
wrote:

> Oh yes, I can do that. I can fix the path.
> I create these node using default session time outs in curator framework..
> I use ExponentialBackoffRetry with retry time out of 1s and retry count
> of 29.
>
> So when I get a remove event for a PEM node... how long  I should wait to
> make sure that its client has given up on tries to rewrite it?
>
> On Wed, Oct 14, 2015 at 3:51 PM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>> Store your PEMs in a known path. Or, store a known value in the node.
>>
>> -JZ
>>
>>
>> On Oct 14, 2015, at 5:49 PM, Vikrant Singh <vikrant.subscribe@gmail.com>
>> wrote:
>>
>> What I  want is to differentiate between "ephemeral nodes" and
>> "persistent ephemeral node".
>>
>> On Wed, Oct 14, 2015 at 3:20 PM, Cameron McKenzie <mckenzie.cam@gmail.com
>> > wrote:
>>
>>> You could keep track of which nodes are ephemeral by looking at the stat
>>> object passed to the NODE_ADDED event in the TreeCache. Then when you get a
>>> NODE_REMOVED event you could check if it's one of your ephemeral nodes?
>>>
>>> On Thu, Oct 15, 2015 at 4:06 AM, Vikrant Singh <
>>> vikrant.subscribe@gmail.com> wrote:
>>>
>>>> yes you got it correct... a slight correction. I am trying to find a
>>>> way where I can make my tree cache event handler aware that "node removed"
>>>> event is coming from a persistent ephemeral node  and delay any action till
>>>> the point the node's curator framework gives up on rewriting the node to
ZK.
>>>>
>>>> On Mon, Oct 12, 2015 at 3:38 PM, Cameron McKenzie <
>>>> mckenzie.cam@gmail.com> wrote:
>>>>
>>>>> So, if I'm understanding correctly, if your application loses its
>>>>> connection to ZooKeeper (or crashes), then a new instance will be started
>>>>> in its place, and if the original instance reconnects then you don't
want
>>>>> it to try and recreate its ephemeral node?
>>>>>
>>>>> If that's the case, then I think that you need additional logic beyond
>>>>> what a PersistentEphemeralNode is going to provide you, as you will need
to
>>>>> check if the node already exists on reconnection.
>>>>>
>>>>> On Tue, Oct 13, 2015 at 8:43 AM, Vikrant Singh <
>>>>> vikrant.subscribe@gmail.com> wrote:
>>>>>
>>>>>> yeah I considered that.. but I ended up using tree cache because
it
>>>>>> gives me more control on the state of tree . I have some custom handlers
>>>>>> for add/remove/update events. Same cache is also used for service
discovery.
>>>>>>
>>>>>> On Mon, Oct 12, 2015 at 2:33 PM, David Kesler <DKesler@yodle.com>
>>>>>> wrote:
>>>>>>
>>>>>>> There’s also already a Curator service discovery extension
library
>>>>>>> that you can look at:
>>>>>>> http://curator.apache.org/curator-x-discovery/index.html.  It’s
>>>>>>> basically boiling down to the same strategy of sticking an ephemeral
node
>>>>>>> into ZK, but with some additional convenience and functionality
built on
>>>>>>> top of it.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* Cameron McKenzie [mailto:mckenzie.cam@gmail.com]
>>>>>>> *Sent:* Monday, October 12, 2015 5:05 PM
>>>>>>> *To:* user@curator.apache.org
>>>>>>> *Subject:* Re: Persistent Ephemeral Node
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> hey Vikrant,
>>>>>>>
>>>>>>> Using a persistent ephemeral node just means that your application
>>>>>>> code doesn't need to worry about handling recreation of the node
when it
>>>>>>> reconnects to ZooKeeper after connection / session loss.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> If your ephemeral node should always be present whenever your
>>>>>>> application instance is running, then this would be a good use
case for a
>>>>>>> persistent ephemeral node.
>>>>>>>
>>>>>>> cheers
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Oct 13, 2015 at 6:03 AM, Vikrant Singh <
>>>>>>> vikrant.subscribe@gmail.com> wrote:
>>>>>>>
>>>>>>> I have some basic question on persistent ephemeral node.
>>>>>>>
>>>>>>> Here is some background...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We have a zoo keeper based service discovery setup. Each service
>>>>>>> register itself as a ephemeral node with zookeeper.When a service
go down
>>>>>>>  its ephemeral node is removed from zookeeper and we know that
service is
>>>>>>> down and we provision it again.
>>>>>>>
>>>>>>> At present we create plain ephemeral node. I am wondering what
>>>>>>> benefit/risks we may get if move to persistent ephemeral ones.
 I see one
>>>>>>> problem... using  plane ephemeral node we can rely on state of
ZK to make a
>>>>>>> decision like service is down. This is because we are sure that
if a node
>>>>>>> get deleted with zoo keeper it will never comeback from same
process. But
>>>>>>> if moved to "persistent ephemeral" I guess same may not be the
case.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Please let me know what you think of the same.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Also I would like to know what are the best scenario where one
>>>>>>> should prefer using persistent ephemeral node over ephemeral
node.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Vikrant
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>

Mime
View raw message