kezhuw opened a new pull request, #2059: URL: https://github.com/apache/zookeeper/pull/2059
It is somewhat well-known that ZooKeeper's sequential node number will overflow finally. It is ok for most usages, but it could also be annoying to handle this overflow in client side in certain cases. It would be really nice for ZooKeeper to support 64-bit sequential number to avoid overflow for long running and high frequency usages. This pr introduces new `CreateMode`s to not break existing usages and uses `zxid` as the sequence number to not change on-disk wire format. The consequence is that: * Not consecutive. There could be hole in two adjacent sequential number. * Fail to create through `multi` with same prefix path. But `multi` does not work well with same path modifications anyway. See [ZOOKEEPER-4695](https://issues.apache.org/jira/browse/ZOOKEEPER-4695). ## ZooKeeper docs about overflow > When creating a znode you can also request that ZooKeeper append a monotonically increasing counter to the end of path. This counter is unique to the parent znode. The counter has a format of %010d -- that is 10 digits with 0 (zero) padding (the counter is formatted in this way to simplify sorting), i.e. "0000000001". See [Queue Recipe](https://zookeeper.apache.org/doc/r3.9.0/recipes.html#sc_recipes_Queues) for an example use of this feature. Note: the counter used to store the next sequence number is a signed int (4bytes) maintained by the parent node, the counter will overflow when incremented beyond 2147483647 (resulting in a name "-2147483648"). ## BookKeeper "depends on" this overflow BookKeeper's [LongZkLedgerIdGenerator](https://github.com/apache/bookkeeper/blob/1666d820a3d98ee6702e39c7cb0ebe51b1fdfd32/bookkeeper-server/src/main/java/org/apache/bookkeeper/meta/LongZkLedgerIdGenerator.java#L299) will fallback to (or rollover) its long version in case of ephemeral sequence overflow. ## Blockers As I documented above, this pr does not work well with `multi`. I created ZOOKEEPER-4695 months ago in discussion of ZOOKEEPER-4655(#1950). If it is good for us to forbid multiple mutations of one key in `multi`, I think this pr is possibly promising as it breaks no implicit dependencies and requires no on-disk wire format change. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
