GitHub user asdf2014 opened a pull request:
https://github.com/apache/zookeeper/pull/262
ZOOKEEPER-2789: Reassign `ZXID` for solving 32bit overflow problem
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.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/asdf2014/zookeeper reassign_zxid
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/zookeeper/pull/262.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #262
----
commit 0d7dabb6b6a42f430223c51a1738e03d4d340c79
Author: asdf2014 <[email protected]>
Date: 2017-05-23T02:02:14Z
ZOOKEEPER-2789: Reassign `ZXID` for solving 32bit overflow problem
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
