Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 9AC632009F3 for ; Fri, 20 May 2016 23:10:48 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 995E0160A2A; Fri, 20 May 2016 21:10:48 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 91B811607AA for ; Fri, 20 May 2016 23:10:47 +0200 (CEST) Received: (qmail 77865 invoked by uid 500); 20 May 2016 21:10:46 -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 77855 invoked by uid 99); 20 May 2016 21:10:46 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 May 2016 21:10:46 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 48D11C0D82 for ; Fri, 20 May 2016 21:10:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.74 X-Spam-Level: ** X-Spam-Status: No, score=2.74 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, KAM_INFOUSMEBIZ=0.75, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_REMOTE_IMAGE=0.01] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=jordanzimmerman-com.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id OhBECqsvo13X for ; Fri, 20 May 2016 21:10:42 +0000 (UTC) Received: from mail-yw0-f169.google.com (mail-yw0-f169.google.com [209.85.161.169]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 401FC5FAD4 for ; Fri, 20 May 2016 21:10:42 +0000 (UTC) Received: by mail-yw0-f169.google.com with SMTP id x194so121156747ywd.0 for ; Fri, 20 May 2016 14:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jordanzimmerman-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=RFFuNuBLRG1+vYOBLufHB8Ww8IydQZ/Geiqea9dfeJw=; b=A7PBUFTJY9c+qnaZPdg8O6ojBRV6ppJtpOkOLlOhzbOKtvneiyfe/HyR+Gmshjin9f bejRnUhEyL9OTGRbLklP5PKqz3qU9BxVb6B8sGgIZLaJMB9CA1+SjqMKKlGBO/bALsq3 p8DR4zo9fbXcktCoPZu7d7v0pJ1R/xzCPBbTpj/Vs5XfNNJZUncBf4Pcy12iDz1S68Q4 slixHdwgqNFOWRmztXNCNyBO/FRBeQkqBF+8+G7EMKXXkbO1FcrfQpNxrdnQErVkLPTs A0N6tPlWG+gW8KpFwMmdCQWnQS5/x0NZFonacxOOZIiUE4EIG/jF6IiCgCaOmde3Yclp zIyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=RFFuNuBLRG1+vYOBLufHB8Ww8IydQZ/Geiqea9dfeJw=; b=mg1kBfTk6xVUeFu34ccoVrbVnLsiIfBY+Nl82sYuaOThFyo7e+obs/QPDEHSu6X0an Ws444weYrZyGxwRcpNWuEB//XbfZOUNl5sUwMWiZjn4cAuiOqwQISsC/PeUUOEYm2RlG DnR0KS0lCB+afDNi8j0LvHA3MuqDFCG2OBlMnSeMk5oIbfdw/dWeLW22N0WbJxpHDQK3 xuZwb1M+NXCmJLyGYpMbybHCYCSxdqcxOC0gvmdFn5mMGji+oLQYTRIL888c8lrq8eG7 tHrEtCmzRAnmpKX0869FPSOJ25FrItlZe3xqqBWLZpmFeVR/uXBENMYf7f623hOFqppb 9Nug== X-Gm-Message-State: AOPr4FU9Lbz2hYsSHL0NdlQeD+8uYufXPouXB/dKhUBBs9SLeI8aECv5tGMXIMrPljUAag== X-Received: by 10.13.243.5 with SMTP id c5mr3531327ywf.40.1463778641072; Fri, 20 May 2016 14:10:41 -0700 (PDT) Received: from [10.0.1.10] ([186.74.13.5]) by smtp.gmail.com with ESMTPSA id d68sm12164312ywe.53.2016.05.20.14.10.38 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 May 2016 14:10:39 -0700 (PDT) From: Jordan Zimmerman Content-Type: multipart/alternative; boundary="Apple-Mail=_997DFCCB-DA51-4F14-B95B-0D91F10F9D9E" Message-Id: <52F7A726-784A-4F2C-BF1D-8EA7389EE520@jordanzimmerman.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: question about curator - retry policy Date: Fri, 20 May 2016 16:10:37 -0500 References: To: user@curator.apache.org In-Reply-To: X-Mailer: Apple Mail (2.3124) archived-at: Fri, 20 May 2016 21:10:48 -0000 --Apple-Mail=_997DFCCB-DA51-4F14-B95B-0D91F10F9D9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Curator=E2=80=99s retry policies are used within each CuratorFramework = operation. For example, when you call client.setData().forPath(p, b) the = retry policy will be invoked if there is a retry-able exception during = the operation. In addition to the retryPolicy, there are connection = timeouts. The behavior of how this is handled changed between Curator = 2.x and Curator 3.x. In Curator 2.x, for every iteration of the retry, = the operation will wait until connection timeout when there=E2=80=99s no = connection. In Curator 3.x, the connection timeout wait only occurs once = (if the default ConnectionHandlingPolicy is used). In any event, ZooKeeper itself tries to maintain the connection. Also, = Curator will re-create the internally managed connection depending = various network interruptions, etc. I=E2=80=99d need to see the logs to = give you more input.=20 -Jordan > On May 19, 2016, at 10:12 AM, Moshiko Kasirer = wrote: >=20 > first i would like to thank you about curator we are using it as part = of our service discovery=20 >=20 > solution and it helps a lot!!=20 >=20 > i have a question i hope you will be able to help me with.=20 >=20 > its regarding the curator retry policy it seems to me we dont really = understand when this policy is=20 >=20 > invoked, as i see in our logs that although i configured it as max = retry 1 actually in the logs i see=20 >=20 > many ZK re connection attempts (and many curator gave up messages but = later i see=20 >=20 > reconnected status...) . is it possible that that policy is only = relevant to manually invoked=20 >=20 > operations against the ZK cluster done via curator ? and that the re = connections i see in the logs=20 >=20 > are caused by the fact that the ZK was available during start up so = sessions were created and=20 >=20 > then when ZK was down the ZK clients (not curator) are sending = heartbeats as part of the ZK=20 >=20 > architecture? that is the part i am failing to understand and i hope = you can help me with that. >=20 > you have recently added RetreyAllways policy and i wanted to know if = it is save to use it?=20 >=20 > the thing is we always want to retry to reconnect to ZK when he is = available but that is something=20 >=20 > the ZK client does as long as he has open sessions right? i am not = sure that it has to do with the=20 >=20 > retry policy ...=20 >=20 > thanks, >=20 > moshiko >=20 > --=20 >=20 > Moshiko Kasirer > Software Engineer > T: +972-74-700-4357 > = = We Create Meaningful Connections > >=20 > This message may contain confidential and/or privileged information.=20= > If you are not the addressee or authorized to receive this on behalf = of the addressee you must not use, copy, disclose or take action based = on this message or any information herein.=20 > If you have received this message in error, please advise the sender = immediately by reply email and delete this message. Thank you. --Apple-Mail=_997DFCCB-DA51-4F14-B95B-0D91F10F9D9E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Curator=E2=80=99s retry policies are used = within each CuratorFramework operation. For example, when you call = client.setData().forPath(p, b) the retry policy will be invoked if there = is a retry-able exception during the operation. In addition to the = retryPolicy, there are connection timeouts. The behavior of how this is = handled changed between Curator 2.x and Curator 3.x. In Curator 2.x, for = every iteration of the retry, the operation will wait until connection = timeout when there=E2=80=99s no connection. In Curator 3.x, the = connection timeout wait only occurs once (if the default = ConnectionHandlingPolicy is used).

In any event, ZooKeeper itself tries to = maintain the connection. Also, Curator will re-create the internally = managed connection depending various network interruptions, etc. I=E2=80=99= d need to see the logs to give you more input. 

-Jordan

On = May 19, 2016, at 10:12 AM, Moshiko Kasirer <moshek@liveperson.com> wrote:

first i would like = to thank you about curator we are using it as part of our service = discovery 

solution and = it helps a lot!! 
i have a = question i hope you will be able to help me with. 

its regarding the curator retry = policy it seems to me we dont really understand when this policy = is 

invoked, =  as i see in our logs that although i configured it as max retry 1 = actually in the logs i see 

many ZK re connection attempts (and many curator gave up = messages but later i see 

reconnected status...) . is it possible that that policy is = only relevant to manually invoked 

operations against the ZK cluster = done via curator ? and that the re connections i see in the = logs 

are caused = by the fact that the ZK was available during start up so sessions were = created and 

then when ZK = was down the ZK clients (not = curator)  are sending heartbeats as part of the = ZK 

architecture? = that is the part i am failing to understand and i hope you can help me = with that.

you have = recently added RetreyAllways policy and i wanted to know if it is save = to use it? 

the thing is = we always want to retry to reconnect to ZK when he is available but that = is something 

the ZK = client does as long as he has open sessions right?  i am not sure = that it has to do with the 

retry policy ... 

thanks,

moshiko

--
=20
Moshiko Kasirer
Software Engineer
T: +972-74-700-4357
We Create Meaningful Connections
=20

This message may contain = confidential and/or privileged information. 
If you are not the addressee or = authorized to receive this on behalf of the addressee you must not use, = copy, disclose or take action based on this message or any information = herein. 
If = you have received this message in error, please advise the sender = immediately by reply email and delete this message. Thank = you.

= --Apple-Mail=_997DFCCB-DA51-4F14-B95B-0D91F10F9D9E--