Return-Path: X-Original-To: apmail-curator-user-archive@minotaur.apache.org Delivered-To: apmail-curator-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id ADB9318336 for ; Mon, 12 Oct 2015 21:41:13 +0000 (UTC) Received: (qmail 60322 invoked by uid 500); 12 Oct 2015 21:41:13 -0000 Delivered-To: apmail-curator-user-archive@curator.apache.org Received: (qmail 60283 invoked by uid 500); 12 Oct 2015 21:41:13 -0000 Mailing-List: contact user-help@curator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@curator.apache.org Delivered-To: mailing list user@curator.apache.org Received: (qmail 60272 invoked by uid 99); 12 Oct 2015 21:41:13 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Oct 2015 21:41:13 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 0C04F180A3F for ; Mon, 12 Oct 2015 21:41:13 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.898 X-Spam-Level: ** X-Spam-Status: No, score=2.898 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id x7QqfFyubbpI for ; Mon, 12 Oct 2015 21:41:12 +0000 (UTC) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id AD8442031C for ; Mon, 12 Oct 2015 21:41:11 +0000 (UTC) Received: by qkas79 with SMTP id s79so62937271qka.0 for ; Mon, 12 Oct 2015 14:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zYxyonxYO1edN5L866QM5dR+So+ZAN837kc+0cxK9pk=; b=FBa9KgmDiZw9tcKjjnBEn3ZQuCAFQgRyYJN9bciaBNlJ6nq2gQTamVYc9B+b6XltRF v7U8It/vPczQjyrfRsjr6iNIPhC88tj4G9vDiLo7yg7NU9XEN+InhUag0dRI5GOhGd03 z73o7BgSVBiEdxCeVGLN8kc0v7q+A6x5zHoZAwedK+TJ3C3wEERB6fB7Qrz9PdeuTUT0 mcveiE7muIjSUNn34gWPFaT8WXisQC0w+n3IDnsOdUT5a6alFYBnC3Q+rmffNI4pQbCv qsgepnQXJpcdQxp7c7E8TPcluFmxE4NS+LIHNuQZ/8J83N5N92muEgGZWTDocFaKnLlV vx9A== MIME-Version: 1.0 X-Received: by 10.55.197.77 with SMTP id p74mr34558889qki.89.1444686065442; Mon, 12 Oct 2015 14:41:05 -0700 (PDT) Received: by 10.140.88.19 with HTTP; Mon, 12 Oct 2015 14:41:05 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Oct 2015 14:41:05 -0700 Message-ID: Subject: Re: Persistent Ephemeral Node From: Vikrant Singh To: user@curator.apache.org Content-Type: multipart/alternative; boundary=001a1149cffabe261a0521ef2f0c --001a1149cffabe261a0521ef2f0c Content-Type: text/plain; charset=UTF-8 thanks for the response... yes I want the same feature i.e. not worrying about recreation of the node if connection loss is temporary. Being said that.. I also want to make sure that we restart a new instance of service when it dies. To do that I am using tree cache, a standby process keep an eye on every node through tree cache and moment it sees one node going down it provision itself as the same. Problem is tree cache does not know about nature of ephemeral nodes. So standby process will treat them same and I will end up in a situation where two processes are trying to create same node. On Mon, Oct 12, 2015 at 2:04 PM, Cameron McKenzie wrote: > 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 >> > > --001a1149cffabe261a0521ef2f0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
thanks for the response... yes I want the same feature i.e= . not worrying about recreation of the node if connection loss is temporary= .
Being said that.. I also want to make sure that we restart a new inst= ance of service when it dies. To do that I am using tree cache, a standby p= rocess keep an eye on every node through tree cache and moment it sees one = node going down it provision itself as the same.

Problem = is tree cache does not know about nature of ephemeral nodes. So standby pro= cess will treat them same and I will end up in a situation where two proces= ses are trying to create same node.


On Mon, Oct 12, 2015 at 2:04 P= M, Cameron McKenzie <mckenzie.cam@gmail.com> wrote:
=
hey Vikrant,
Using a pe= rsistent ephemeral node just means that your application code doesn't n= eed to worry about handling recreation of the node when it reconnects to Zo= oKeeper after connection / session loss.

If your e= phemeral node should always be present whenever your application instance i= s running, then this would be a good use case for a persistent ephemeral no= de.
cheers


On Tu= e, Oct 13, 2015 at 6:03 AM, Vikrant Singh <vikrant.subscribe@gma= il.com> wrote:
I have some basic question on persistent ephemeral node.=C2=A0

=
Here is some background...

We have a zoo keep= er based service discovery setup. Each service register itself as a ephemer= al node with zookeeper.When a service go down =C2=A0its ephemeral node is r= emoved from zookeeper and we know that service is down and we provision it = again.=C2=A0

At present we create plain ephemeral node. I am wonderi= ng what benefit/risks we may get if move to persistent ephemeral ones.=C2= =A0 I see one problem... using=C2=A0 plane ephemeral node we can rely on st= ate of ZK to make a decision like service is down. This is because we are s= ure 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 no= de over ephemeral node.=C2=A0

Thanks,
Vi= krant


--001a1149cffabe261a0521ef2f0c--