[
https://issues.apache.org/jira/browse/BOOKKEEPER-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13625373#comment-13625373
]
Flavio Junqueira commented on BOOKKEEPER-552:
---------------------------------------------
If I understand it correctly, the number of slots can't change for a given
deployment and every server has to agree on that number. This is possibly also
a problem for upgrades, in the case we want to change that number in a given
setting.
Writing to ZooKeeper seems to be a good way to guarantee agreement and to lock
the value, but I don't think we can change that value for an existing
deployment even if everyone agrees on the value because it will lead to an
incorrect mapping for ledgers created with the old value.
A couple of other comments:
- "competition" in the preamble of ZkBatchLedgerIdGenerator should be
"contention" instead.
- in fetchLedgerIdBatch, you probably want to resubmit the getData operation in
the case of a connection loss event.
> 64 Bits Ledger ID Generation
> ----------------------------
>
> Key: BOOKKEEPER-552
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-552
> Project: Bookkeeper
> Issue Type: Sub-task
> Components: bookkeeper-client, bookkeeper-server, hedwig-server
> Reporter: Jiannan Wang
> Assignee: Jiannan Wang
> Fix For: 4.3.0
>
> Attachments: BOOKKEEPER-552.patch, BOOKKEEPER-552.patch,
> BOOKKEEPER-552.patch
>
>
> This task aims to find and implement 64 bits global unique ledger id
> generation mechanisms.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
