*Can anyone from your team describe how did you guys extend the ledgermanager? I am interested in how did you guys handle backward compatibilityfor Hierarchical Ledger Manager.*
We created LongHierarchicalLedgerManager, which would work for *positive long* ledgerids (so technically only 63 bits for ledgerid). This LongHierarchicalLedgerManager extends HierarchicalLedgerManager and its logic is similar to HierarchicalLedgerManager. But instead of using 2-level hierarchical znodes (2-4-4 split), we use 4-level hierarchical znode with 3-4-4-4-4 split. We didn't plan for backward compatibility for HierarchicalLedgerManager, since we started the cluster with LongHierarchicalLedgerManager, we were ok with it. Thanks, Charan On Wed, Oct 26, 2016 at 3:49 PM, Matteo Merli <mme...@apache.org> wrote: > On Wed, Oct 26, 2016 at 11:45 AM Venkateswara Rao Jujjuri < > jujj...@gmail.com> > wrote: > > > - Ledgers are unique across multiple clusters. Useful if storage tiers > with > > different stores are employed. > > > > For this you could combine the ledgerId with another 64bit id, that could > encode the rest of the required informations ( storage tier, cluster, .. ) > > > > - No centralized id creation - Allows client to give the name instead of > > server generating name on create. > > > > This should be already possible with your changes in 4.4, right? > > Wouldn't be enough to combine the 64bit ledgerId with an additional id that > doesn't need to flow through BK ? >
