On Fri, Oct 28, 2016 at 5:01 PM, Charan Reddy G <reddychara...@gmail.com>
wrote:
> In our last meeting, we briefly discussed about options of handling
> negative long ledgerids in LongeHierarchicalLedgerManager. Mainly by using
> the unsigned long value (20 digits) for determining the ledger zNode path.
> I see couple of problems with that
>
> (signed long) -> (unsigned long)
> -9223372036854775808 -> "09223372036854775808"
> 9223372036854775807 -> "09223372036854775807"
>
> now both these ledger znodes would be under the same parent zNode
> 0922/3372/0368/5477
>
> gc method in ScanAndCompareGarbageCollector, for LedgerRange
> (0922/3372/0368/5477) the following logic would break. Because we would get
> mix of positive and negative ledgerids in this ledgerrange and
> scanandcompare logic with bkActiveLedgers (ledgerStorage.getActiveLedgers)
> will not work.
>
>
> while(ledgerRangeIterator.hasNext()) {
> LedgerRange lRange = ledgerRangeIterator.next();
>
> Long start = lastEnd + 1;
> Long end = lRange.end();
> if (!ledgerRangeIterator.hasNext()) {
> end = Long.MAX_VALUE;
> }
>
> Iterable<Long> subBkActiveLedgers =
> bkActiveLedgers.subSet(start, true, end, true);
>
> and also with ledgerrange with all negative ledgerids we need to do some
> tweaking for the 'start' and the 'end'.
>
> So in summary, I feel its risky to use unsigned long for determining the
> ledger zNode path, since we used signed long for ledgerids all across the
> codebase and this inconsistency can cause issue in some other areas as
> well.
>
> So I'm more convinced to use the signed long for determining the ledger
> zNode path and let the LongHierarchicalLedgerManager/Iterator deal with
> negative ledgerids accordingly (for eg. deal with znode with '-' while
> doing comparison and iteration). So it makes scope of the change limited to
> LongHierarchicalLedgerManager rather than applying patches to other areas.
>
> (ledger id) -> (znode path)
> -9223372036854775808 -> "-922/3372/0368/5477/5808"
> 9223372036854775807 -> "0922/3372/0368/5477/5807"
>
Or shall we just simply not use negative numbers?
>
> Thanks,
> Charan
>
>
> On Wed, Oct 26, 2016 at 10:55 PM, Sijie Guo <si...@apache.org> wrote:
>
> > 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,
> ..
> > )
> > >
> >
> > +1 on this idea
> >
> >
> > >
> > >
> > > > - 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 ?
> > >
> >
>
