zoo_set() version question

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

zoo_set() version question

Avery Ching
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?

Thanks!

Avery

Reply | Threaded
Open this post in threaded view
|

Re: zoo_set() version question

Patrick Hunt
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
Reply | Threaded
Open this post in threaded view
|

Re: zoo_set() version question

Avery Ching
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" <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: zoo_set() version question

Patrick Hunt
Could you explain your use case? There is no way to get the version as
part of a zoo_set, however there may be some alternative that we can
suggest if we knew more about the problem you are trying to solve.

Patrick

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" <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: zoo_set() version question

Mahadev Konar
In reply to this post by Avery Ching
Hi Avery,
 If you are using zoo_set( **** , int version),

And you have a success, then the version of the node that denots your
successful zoo_set() above is
 = Version +1

Are you  using it to keep track of what revision is the one valid for your
set's?


mahadev

On 12/12/08 11:36 AM, "Avery Ching" <[hidden email]> 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" <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: zoo_set() version question

Mahadev Konar
Also I am assuming that you are not using version = -1. -1 means that it
overrides the data on that node.

mahadev

On 12/12/08 12:12 PM, "Mahadev Konar" <[hidden email]> wrote:

> Hi Avery,
>  If you are using zoo_set( **** , int version),
>
> And you have a success, then the version of the node that denots your
> successful zoo_set() above is
>  = Version +1
>
> Are you  using it to keep track of what revision is the one valid for your
> set's?
>
>
> mahadev
>
> On 12/12/08 11:36 AM, "Avery Ching" <[hidden email]> 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" <[hidden email]> 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
>>

Reply | Threaded
Open this post in threaded view
|

Re: zoo_set() version question

Patrick Hunt
In reply to this post by Mahadev Konar
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" <[hidden email]> 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" <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: zoo_set() version question

Avery Ching
In reply to this post by Patrick Hunt
I am working on clusterlib (YST project) and we are using zookeeper for a
backing store of cluster abstractions (i.e. Applications, groups, nodes,
data distributions, etc.).

I believe that this is an optimization use case for using zoo_set() with
versions that are != -1.

I.e.

1.  I do a successful zoo_set() with version V, where V != -1.
2.  Make more changes to my data.
3.  I want to do another zoo_set() but I don't know what version number to
try.

Since I don't know the version number I have to use either zoo_exists() or
zoo_get().  Even though zoo_exists() gets me the version number I don't know
whether that version is the one that I wrote.  Therefore I need to read the
znode (zoo_get()) and compare with the data that I did set before I make
changes to the data (step 2) ) that I will zoo_set in step 3).  Note that I
am never sure if I was the last writer.

If there is a way to get the used version from zoo_set(), then I do not need
to use zoo_exists() or zoo_get() in between zoo_set() calls (steps 1) and 3)
).  They will still fail, of course, if the version is wrong.  And the other
benefit is that I will know that I was the last writer if I get the version
from my last successful zoo_set() and then do zoo_exists() and the versions
match.

Avery

On 12/12/08 11:53 AM, "Patrick Hunt" <[hidden email]> wrote:

> Could you explain your use case? There is no way to get the version as
> part of a zoo_set, however there may be some alternative that we can
> suggest if we knew more about the problem you are trying to solve.
>
> Patrick
>
> 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" <[hidden email]> 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
>>

Reply | Threaded
Open this post in threaded view
|

RE: zoo_set() version question

Benjamin Reed-2
I looked into this a bit more since i remembered that the protocol returns the stat structure. it turns out to be a bug in the C API. in java, both the sync and async version of setData will give you a stat structure back. in C, zoo_aset uses the stat_completion_t, so you get the stat structure back. unfortunately zoo_set() does not return the stat structure. i think we should open a bug on this.

ben

________________________________________
From: Avery Ching [[hidden email]]
Sent: Friday, December 12, 2008 12:41 PM
To: Patrick Hunt
Cc: [hidden email]
Subject: Re: zoo_set() version question

I am working on clusterlib (YST project) and we are using zookeeper for a
backing store of cluster abstractions (i.e. Applications, groups, nodes,
data distributions, etc.).

I believe that this is an optimization use case for using zoo_set() with
versions that are != -1.

I.e.

1.  I do a successful zoo_set() with version V, where V != -1.
2.  Make more changes to my data.
3.  I want to do another zoo_set() but I don't know what version number to
try.

Since I don't know the version number I have to use either zoo_exists() or
zoo_get().  Even though zoo_exists() gets me the version number I don't know
whether that version is the one that I wrote.  Therefore I need to read the
znode (zoo_get()) and compare with the data that I did set before I make
changes to the data (step 2) ) that I will zoo_set in step 3).  Note that I
am never sure if I was the last writer.

If there is a way to get the used version from zoo_set(), then I do not need
to use zoo_exists() or zoo_get() in between zoo_set() calls (steps 1) and 3)
).  They will still fail, of course, if the version is wrong.  And the other
benefit is that I will know that I was the last writer if I get the version
from my last successful zoo_set() and then do zoo_exists() and the versions
match.

Avery

On 12/12/08 11:53 AM, "Patrick Hunt" <[hidden email]> wrote:

> Could you explain your use case? There is no way to get the version as
> part of a zoo_set, however there may be some alternative that we can
> suggest if we knew more about the problem you are trying to solve.
>
> Patrick
>
> 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" <[hidden email]> 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
>>

Reply | Threaded
Open this post in threaded view
|

Re: zoo_set() version question

Patrick Hunt
huh, we should use our APIs more. ;-)

Ben can you open a jira on this? Mark it fix for 3.1.0.

Patrick

Benjamin Reed wrote:

> I looked into this a bit more since i remembered that the protocol
> returns the stat structure. it turns out to be a bug in the C API. in
> java, both the sync and async version of setData will give you a stat
> structure back. in C, zoo_aset uses the stat_completion_t, so you get
> the stat structure back. unfortunately zoo_set() does not return the
> stat structure. i think we should open a bug on this.
>
> ben
>
> ________________________________________ From: Avery Ching
> [[hidden email]] Sent: Friday, December 12, 2008 12:41 PM To:
> Patrick Hunt Cc: [hidden email] Subject: Re:
> zoo_set() version question
>
> I am working on clusterlib (YST project) and we are using zookeeper
> for a backing store of cluster abstractions (i.e. Applications,
> groups, nodes, data distributions, etc.).
>
> I believe that this is an optimization use case for using zoo_set()
> with versions that are != -1.
>
> I.e.
>
> 1.  I do a successful zoo_set() with version V, where V != -1. 2.
> Make more changes to my data. 3.  I want to do another zoo_set() but
> I don't know what version number to try.
>
> Since I don't know the version number I have to use either
> zoo_exists() or zoo_get().  Even though zoo_exists() gets me the
> version number I don't know whether that version is the one that I
> wrote.  Therefore I need to read the znode (zoo_get()) and compare
> with the data that I did set before I make changes to the data (step
> 2) ) that I will zoo_set in step 3).  Note that I am never sure if I
> was the last writer.
>
> If there is a way to get the used version from zoo_set(), then I do
> not need to use zoo_exists() or zoo_get() in between zoo_set() calls
> (steps 1) and 3) ).  They will still fail, of course, if the version
> is wrong.  And the other benefit is that I will know that I was the
> last writer if I get the version from my last successful zoo_set()
> and then do zoo_exists() and the versions match.
>
> Avery
>
> On 12/12/08 11:53 AM, "Patrick Hunt" <[hidden email]> wrote:
>
>> Could you explain your use case? There is no way to get the version
>> as part of a zoo_set, however there may be some alternative that we
>> can suggest if we knew more about the problem you are trying to
>> solve.
>>
>> Patrick
>>
>> 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" <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: zoo_set() version question

Mahadev Konar
In reply to this post by Patrick Hunt
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" <[hidden email]> 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" <[hidden email]> 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" <[hidden email]> 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
>>

Reply | Threaded
Open this post in threaded view
|

Re: zoo_set() version question

Patrick Hunt
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" <[hidden email]> 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" <[hidden email]> 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" <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: zoo_set() version question

Avery Ching
If I can get the version number from zoo_set(), it doesn't really matter
from my point of view that the version number is always += 1, only that it
is increasing.

Avery


On 12/12/08 2:24 PM, "Patrick Hunt" <[hidden email]> wrote:

> 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" <[hidden email]> 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" <[hidden email]> 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" <[hidden email]> 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
>>

Reply | Threaded
Open this post in threaded view
|

RE: zoo_set() version question

Krishna Sankar (ksankar)
In reply to this post by Patrick Hunt
Most probably we shouldn't explicitly state the increment count but that
it will increase. Also is there a rest/overflow condition ?
Cheers
<k/>

|-----Original Message-----
|From: Patrick Hunt [mailto:[hidden email]]
|Sent: Friday, December 12, 2008 2:24 PM
|To: Mahadev Konar
|Cc: [hidden email]
|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" <[hidden email]> 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" <[hidden email]> 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" <[hidden email]> 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
|>
Reply | Threaded
Open this post in threaded view
|

Re: zoo_set() version question

Mahadev Konar
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)" <[hidden email]> wrote:

> Most probably we shouldn't explicitly state the increment count but that
> it will increase. Also is there a rest/overflow condition ?
> Cheers
> <k/>
>
> |-----Original Message-----
> |From: Patrick Hunt [mailto:[hidden email]]
> |Sent: Friday, December 12, 2008 2:24 PM
> |To: Mahadev Konar
> |Cc: [hidden email]
> |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" <[hidden email]> 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" <[hidden email]> 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" <[hidden email]> 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
> |>