From user-return-11874-archive-asf-public=cust-asf.ponee.io@zookeeper.apache.org Fri Mar 15 22:55:12 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id C6C88180627 for ; Fri, 15 Mar 2019 23:55:11 +0100 (CET) Received: (qmail 13231 invoked by uid 500); 15 Mar 2019 22:55:10 -0000 Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@zookeeper.apache.org Delivered-To: mailing list user@zookeeper.apache.org Received: (qmail 13219 invoked by uid 99); 15 Mar 2019 22:55:09 -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, 15 Mar 2019 22:55:09 +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 58343C2896 for ; Fri, 15 Mar 2019 22:55:09 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=6.31 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] 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-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 23zDbqWd6VEI for ; Fri, 15 Mar 2019 22:55:07 +0000 (UTC) Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 7DA1B5F4AB for ; Fri, 15 Mar 2019 22:55:07 +0000 (UTC) Received: by mail-ua1-f53.google.com with SMTP id 46so2154669uan.8 for ; Fri, 15 Mar 2019 15:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jordanzimmerman-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=KIkB2BBE7v2SvdvFPUI5+N4DwPY1Taj1InMUJrQlzkY=; b=IqIoGYGcli9hk+Jf8NwCcmqBanCjG8HqJp6eLzIukfB0iVbbiNvqg+RtufpggXSZQc cxB7sIDZQymoVjPi+wSIXhBZhlKC7yKfi76ayHVRgVy6zvgkxuYBRDWFvoubf4g1ZBLH v7cb5j/EvdOr0CnlTPHyxRtzg9UGeF1AnvuYGnlAcA5TkOwXb42O8071+ihgJqwXq4qQ h9kQ3iiLH4+I8CWB+l7tyPfFaEONpLTyl4/BdXAIO9mYmqEx+Vx6HqsPfcjSmGtLcqCZ Atsa0RzoFXchzi5PF5lMou32Q9z50u2gys38eE5lgZu6dwT5tT1JRyV4X4jUFIn05B6J v/Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=KIkB2BBE7v2SvdvFPUI5+N4DwPY1Taj1InMUJrQlzkY=; b=DXdxPxU8MvwuQ+7DuE1LFFB2uvrag4Qu4XSSc5JXVHWaQMdPfXnvpGGvt0xBNU4rc4 JubjRH91L/AWFYpH1yyC8ZEHJQG7MrBp6OBPuge0zG+TRfZn7Cfof4K0M/qR/F8EDOKi DNRAm3UGuqARzli0zHRfu4BLL65Q4GfVAwtU6wDBVBADrdwd/GrYurO2+W7SoxdwkuKr RUo1bEs5hvv1+40QliT9ciP+wjkQ7XRmu/UfQgXCA/rJLX2XKXTjWNCXYRcbSbooIpgF Fhv5rk0CwN4PnlkiJyVlQaVWZDqRRjBxM2+E694fs4D94AmDzJ0A/XbrA/b4vA8mGmVc 6Wfw== X-Gm-Message-State: APjAAAVr/T119yE2Qff3Z0Xb7ww+TPULzHpLawGcc4NR2ADelqCvCuQS zVuo4UEHQv0J1HCnPOVabfFWVe6fNajF5A== X-Google-Smtp-Source: APXvYqwdElV/LhJcgh9OKivhYVbuqDqgkqyeVpy8JyqbFlTU1ukCyuPHLxudQMjnF3RCSY8J9OCxWQ== X-Received: by 2002:ab0:604a:: with SMTP id o10mr1056904ual.21.1552690506373; Fri, 15 Mar 2019 15:55:06 -0700 (PDT) Received: from [192.168.100.128] ([45.7.238.16]) by smtp.gmail.com with ESMTPSA id f188sm915625vke.38.2019.03.15.15.55.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Mar 2019 15:55:05 -0700 (PDT) From: Jordan Zimmerman Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Zookeeper syncing with Curator Date: Fri, 15 Mar 2019 16:54:51 -0600 References: <7FCB76B1-75D5-413E-8599-6329F2D3FA54@jordanzimmerman.com> To: user@zookeeper.apache.org In-Reply-To: Message-Id: <32AB6021-44D3-456F-AFA7-2B83D4742302@jordanzimmerman.com> X-Mailer: Apple Mail (2.3445.9.1) Curator does nothing additional with sync. Sync is a feature of = ZooKeeper not Curator. Curator merely exposes an API for it. -JZ > On Mar 14, 2019, at 9:35 AM, Robin Wolters = wrote: >=20 > That is indeed an option, thanks. >=20 > But for my own curiosity, how does the sync operation behave for = Curator? > 1) Does it also sync the child nodes of the specified path? > 2) Does it sync (transfer data for) a node even if it was up to date? > 3) In Curator, would I have to wait for the callback of sync or can I > just use sync and go ahead, knowing the next operation is queued? >=20 > Regards, > Robin >=20 > On Wed, 13 Mar 2019 at 17:07, Jordan Zimmerman > wrote: >>=20 >> It sounds like you=E2=80=99re describing one of the Barrier recipes. = Curator has several. I=E2=80=99d look to those as a possible solution. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Jordan Zimmerman >>=20 >>> On Mar 13, 2019, at 9:56 AM, Robin Wolters = wrote: >>>=20 >>> Thanks for the reply. I understand that this is not possible in = general. >>>=20 >>> In my case the read and write are started from the same overarching >>> application (but different zookeeper connections and hence possibly >>> different nodes). >>> I start the read only after I know the write has succeeded, but I >>> don't know if it has reached all nodes yet. >>> So I expected that a sync gives me the guarantee that the next read >>> reflects at least this specific write. >>> It's okay if possible further writes are not in yet. >>>=20 >>> Is this "selective" consistency not possible with my approach? >>>=20 >>> Best regards, >>> Robin >>>=20 >>> On Wed, 13 Mar 2019 at 15:47, Jordan Zimmerman >>> wrote: >>>>=20 >>>> ZooKeeper is an eventually consistent system. Reads are always = consistent in that they reflect previous writes, however it is not = possible to do what you describe. Reads are fulfilled by the Node your = client is connected to. Writes are always through the leader Node. In a = dynamic ensemble with lots of concurrent reads/writes there is no such = thing a read reflecting all active writes. >>>>=20 >>>> You should consider a RDBMS like MySQL instead of something like = ZooKeeper. >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> Jordan Zimmerman >>>>=20 >>>>> On Mar 13, 2019, at 6:37 AM, Robin Wolters = wrote: >>>>>=20 >>>>> Hello, >>>>>=20 >>>>> I use Zookeeper in a cluster setup and some of my read operations = need >>>>> to be consistent, meaning I have to make sure that a read always >>>>> reflects all previous writes (which might be performed on another >>>>> zookeeper server and has not reached all other instances). >>>>> The idea is to force a sync before those reads to make them >>>>> =E2=80=9Cconsistent=E2=80=9D reads with: >>>>> client.sync().forPath(path) >>>>>=20 >>>>> For this, I have these questions left: >>>>> 1. Do you need to manually await the callback of sync before = reading, >>>>> or is the next read operation queued until the sync is complete? >>>>> 2. Which amount of data is transferred between the nodes in this = kind >>>>> of manual sync? >>>>> a) Does it always transfer and process data from the master server >>>>> even if the syncing node is up-to-date on this path - or only for >>>>> those nodes that are really out of sync (i.e. sync only possible >>>>> deltas)? >>>>> b) Does a sync on the path also force the parent nodes to sync? >>>>> c) Does a sync on the path also force all child nodes to sync? >>>>> d) How would one manually sync the complete data (as the regular >>>>> sync does) of a node? Is client.sync().forPath("/") the way to do >>>>> this? >>>>>=20 >>>>> Anyone experiences with this? >>>>>=20 >>>>> Best regards, >>>>> Robin