In the case of cversion, I'd say that we need to error out the request because
wrapping around might break recipes that use the minimum. For version, we could
wrap it to zero, but we could also error out just to keep it consistent with
the behavior of the other fields (e.g., cversion).
-Flavio
On Thursday, April 16, 2015 10:14 AM, Michi Mutsuzaki
<[email protected]> wrote:
How should we deal with cversions? we probably shouldn't wrap to zero
since cversions are used for sequential nodes, right?
On Thu, Apr 16, 2015 at 1:55 AM, Flavio Junqueira
<[email protected]> wrote:
> It is indeed related, Michi, thanks for the pointers. I was thinking that at
> least in the case of versions, we could just wrap it to zero rather than let
> it become negative. Since we only check for equality, wrapping it to zero
> when it hits Integer.MAX_VALUE should be sufficient.
> I'll generate a patch for this.
> -Flavio
>
>
> On Thursday, April 16, 2015 12:59 AM, Michi Mutsuzaki
><[email protected]> wrote:
>
>
>
> I guess this is the mailing list discussion you are referring to:
> http://s.apache.org/qMw , I couldn't find an open JIRA for this. I
> filed a similar issue for client xid:
> https://issues.apache.org/jira/browse/ZOOKEEPER-1485
>
>
>
> On Wed, Apr 15, 2015 at 1:51 PM, Flavio Junqueira <[email protected]> wrote:
>> I was checking checkAndIncVersion in PrepRequestProcessor and we currently
>> don't do anything special for wrapping around the version counter of a znode
>> in the case it reaches the max int value. The problem is that incrementing
>> the max value will give us negative values, and in principle versions are
>> non-negative values.
>>
>> It is unlikely that most applications will hit it ever, but I was wondering
>> if this has ever been a problem to anyone, and if there is any jira created
>> about it. I searched and couldn't find anything, but I do remember a
>> discussion about counters overflowing some time back.
>>
>> I'd appreciate feedback here.
>>
>> Thanks,
>> -Flavio
>
>
>
>
