[
https://issues.apache.org/jira/browse/BOOKKEEPER-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13630982#comment-13630982
]
Ivan Kelly commented on BOOKKEEPER-590:
---------------------------------------
Perhaps the problem is then that GC is dependent on the logic of the ledger
manager but should be independent. i.e. GC should just pass the list of active
ledgers to the ledger manager, and the ledger manager should return the list of
ledgers to remove. This would get around the issue of ledger managers which
don't provide ordering guarantees also.
> Another Scan-And-Compare GC Implementation
> ------------------------------------------
>
> Key: BOOKKEEPER-590
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-590
> Project: Bookkeeper
> Issue Type: Improvement
> Components: bookkeeper-server
> Reporter: Jiannan Wang
> Assignee: Jiannan Wang
> Attachments: BOOKKEEPER-590.patch
>
>
> The idea of Scan-And-Compare GC is as below:
> * Assume the ledger id list in local bookie server is *LocalLedgers*
> * At the same time, the ledger id list at metadata storage is *LiveLedgers*
> * Then the ledgers require garbage collection are *LocalLedgers -
> LiveLedgers*
> Under current implementation, an ledger id order guarantee is required when
> obtain *LiveLedgers* from metadata storage. However, this is unnecessary: we
> get *LocalLedgers* and we can just remove elements that in *LiveLedgers* one
> by one in any order.
> What's more, without the order requirement when scan all ledger ids, some
> things become simple:
> * We even don't need radix tree to maintain 64-bits ledger metadata, a
> hierarchical hash tree is enough (just as what topic metadata management
> does).
> * Easy to handle 64-bit ledger id backward compatibility for
> MSLedgerManager:
> ** Currently, for MSLedgerManager, we format ledger id to a fixed
> length (it's 10 now) digit string to make order scan
> ** When a 64-bit ledger id is used we need to enlarge the fixed length,
> then old ledger id backward compatibility turns to be a trouble if we require
> this order guarantee.
> As above reasons, it would better to remove specific order requirement from
> current Scan-And-Compare GC implementation.
--
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
