Thanks for clarification on the implementation. When you guys contribute the change back, it might be worth considering using 2-4-4 split for ledger ids whose higher 32 bits is 0. So it can backward compatible with existing HirarchicalLedgerManager.
- Sijie On Wed, Oct 26, 2016 at 4:36 PM, Charan Reddy G <reddychara...@gmail.com> wrote: > *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 ? > > >
