zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-2789) Reassign `ZXID` for solving 32bit overflow problem
Date Thu, 14 Dec 2017 16:14:00 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16291100#comment-16291100
] 

ASF GitHub Bot commented on ZOOKEEPER-2789:
-------------------------------------------

Github user breed commented on the issue:

    https://github.com/apache/zookeeper/pull/262
  
    i think it would be much better to extend ZOOKEEPER-1277 to more transparently do the
rollover without a full leader election.
    
    the main issue i have with shortening the epoch size is that once the epoch hits the maximum
value the ensemble is stuck, nothing can proceed, so we really need to keep the epoch size
big enough that we would never hit that condition. i don't think a 16-bit epoch satisfies
that requirement.


> Reassign `ZXID` for solving 32bit overflow problem
> --------------------------------------------------
>
>                 Key: ZOOKEEPER-2789
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2789
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: quorum
>    Affects Versions: 3.5.3
>            Reporter: Benedict Jin
>            Assignee: Benedict Jin
>             Fix For: 3.6.0
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> If it is `1k/s` ops, then as long as $2^32 / (86400 * 1000) \approx 49.7$ days ZXID will
exhausted. But, if we reassign the `ZXID` into 16bit for `epoch` and 48bit for `counter`,
then the problem will not occur until after  $Math.min(2^16 / 365, 2^48 / (86400 * 1000 *
365)) \approx Math.min(179.6, 8925.5) = 179.6$ years.
> However, i thought the ZXID is `long` type, reading and writing the long type (and `double`
type the same) in JVM, is divided into high 32bit and low 32bit part of the operation, and
because the `ZXID` variable is not  modified with `volatile` and is not boxed for the corresponding
reference type (`Long` / `Double`), so it belongs to [non-atomic operation] (https://docs.oracle.com/javase/specs/jls/se8
/html/jls-17.html#jls-17.7). Thus, if the lower 32 bits of the upper 32 bits are divided into
the entire 32 bits of the `long`, there may be a concurrent problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message