From zookeeper-user-return-144-apmail-hadoop-zookeeper-user-archive=hadoop.apache.org@hadoop.apache.org Fri Dec 12 23:33:04 2008 Return-Path: Delivered-To: apmail-hadoop-zookeeper-user-archive@locus.apache.org Received: (qmail 29233 invoked from network); 12 Dec 2008 23:33:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Dec 2008 23:33:03 -0000 Received: (qmail 37295 invoked by uid 500); 12 Dec 2008 23:33:16 -0000 Delivered-To: apmail-hadoop-zookeeper-user-archive@hadoop.apache.org Received: (qmail 37278 invoked by uid 500); 12 Dec 2008 23:33:16 -0000 Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: zookeeper-user@hadoop.apache.org Delivered-To: mailing list zookeeper-user@hadoop.apache.org Received: (qmail 37267 invoked by uid 99); 12 Dec 2008 23:33:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Dec 2008 15:33:16 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [216.145.54.173] (HELO mrout3.yahoo.com) (216.145.54.173) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Dec 2008 23:32:53 +0000 Received: from SNV-EXBH01.ds.corp.yahoo.com (snv-exbh01.ds.corp.yahoo.com [207.126.227.249]) by mrout3.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id mBCNWOip076556 for ; Fri, 12 Dec 2008 15:32:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:user-agent:date:subject:from:to:message-id: thread-topic:thread-index:in-reply-to:mime-version:content-type: content-transfer-encoding:return-path:x-originalarrivaltime; b=qoI9kSlw5NAIlxhtN9Te/jFCXBTvPkREnhSDcpbNZI/hHmq6HprZFRVBCWaQ20hZ Received: from SNV-EXVS09.ds.corp.yahoo.com ([207.126.227.86]) by SNV-EXBH01.ds.corp.yahoo.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 15:32:24 -0800 Received: from 10.73.146.106 ([10.73.146.106]) by SNV-EXVS09.ds.corp.yahoo.com ([207.126.227.84]) via Exchange Front-End Server snv-webmail.corp.yahoo.com ([207.126.227.59]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Dec 2008 23:31:58 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Fri, 12 Dec 2008 15:31:57 -0800 Subject: Re: zoo_set() version question From: Mahadev Konar To: Message-ID: Thread-Topic: zoo_set() version question Thread-Index: AclcqGs5WQmWLFpdSLaaUUFltoLX5QABOjoQAAEfocg= In-Reply-To: <9FA16888AD1BF64ABCE6C2532CCEB98A063237A9@xmb-sjc-219.amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Dec 2008 23:32:24.0291 (UTC) FILETIME=[E2ECDB30:01C95CB1] X-Virus-Checked: Checked by ClamAV on apache.org Maybe you guys are right! If we are returning the stat we should not explicitly state it. As long as we don't have a dire need for it, we shouldn't make it a guarantee on zookeeper. @krishna, the count does overflow. Its an int. the calculation we did was that even if we have 100 processes updating a node 10,000 times a day, it would take around 5 years before you overflow the int. mahadev On 12/12/08 3:07 PM, "Krishna Sankar (ksankar)" wrote: > Most probably we shouldn't explicitly state the increment count but that > it will increase. Also is there a rest/overflow condition ? > Cheers > > > |-----Original Message----- > |From: Patrick Hunt [mailto:phunt@apache.org] > |Sent: Friday, December 12, 2008 2:24 PM > |To: Mahadev Konar > |Cc: zookeeper-user@hadoop.apache.org > |Subject: Re: zoo_set() version question > | > |That's fine, but we should document it. Please enter a JIRA that the > |docs should talk about this. > | > |I notice we have this in the prog guide: > |"Each time a znode's data changes, the version number increases." > | > |Sort of a moot point once we fix the zoo_set api but we should > |explicitly state that it increments by 1. > | > |Patrick > | > |Mahadev Konar wrote: > |> That's right pat. I thought about that. Though ben already mentioned > |that we > |> missed the stat return in the c sync code. > |> But for the version, since its a test and set, we should also > |guarantee that > |> the version is a +1 to prev one. It would be really unintutive if it > |was > |> otherwise. > |> > |> Also I noticed after ben's comments that the async callback > zoo_aset() > |is > |> called back with stat argument. Only the zoo_get() sync api is > missing > |stat > |> return code :). > |> > |> > |> mahadev > |> > |> On 12/12/08 12:39 PM, "Patrick Hunt" wrote: > |> > |>> Mahadev Konar wrote: > |>>> And you have a success, then the version of the node that denots > |your > |>>> successful zoo_set() above is > |>>> = Version +1 > |>> Mahadev, that's the current implementation, but I wasn't aware we > |were > |>> exposing that detail as something users should rely on. Is it > |documented > |>> anywhere in the docs? If this is "user visible" we should document > |it, I > |>> thought we weren't exposing this for a reason... > |>> > |>>> > |>>> mahadev > |>>> > |>>> On 12/12/08 11:36 AM, "Avery Ching" wrote: > |>>> > |>>>> Patrick, > |>>>> > |>>>> Thanks for responding. > |>>>> > |>>>> I agree that I can use zoo_exists and zoo_get to get the version > of > |the > |>>>> znode as it exists currently. > |>>>> > |>>>> The problem I am trying to solve is that getting the version from > |struct > |>>>> Stat in either zoo_exists or zoo_get may not be the same version > |that my > |>>>> last successful zoo_set used. I would like to get the version > that > |denotes > |>>>> my last successful zoo_set() operation to a particular znode. > |>>>> > |>>>> I understand that the data and version to the znode may change > |immediately > |>>>> one or multiple times after my zoo_set() and this is fine, but I > |would still > |>>>> like to know the znode's versions of the data I set. > |>>>> > |>>>> Avery > |>>>> > |>>>> On 12/12/08 11:11 AM, "Patrick Hunt" wrote: > |>>>> > |>>>>> Avery Ching wrote: > |>>>>>> If zoo_set() completes successfully with version != -1, can we > |assume that > |>>>>>> version -> version + 1 for this znode? If not, is there a way > |for the > |>>>>>> user > |>>>>>> to get the version of the successfully completed zoo_set() > |operation? > |>>>>> You shouldn't rely on this, it may work, but it's not part of the > |>>>>> contract. Also, nothing says that some other client won't change > |the > |>>>>> node immediately after you change it. > |>>>>> > |>>>>> You can access the version using zoo_exists or zoo_get - > |specifically > |>>>>> the "struct Stat stat" argument of either of those methods > |contains a > |>>>>> "version" member. > |>>>>> > |>>>>> Patrick > |>