Re: [Discuss] 64 bits ledger id

Hi JV, Do I understand correctly that you're proposing to generate 128-bit UUIDs locally to use as ledger ids? If so, I'm concerned that even if the probability of collision is low, there is still a chance of having collisions with no way to verify in the case you aren't relying on a metadata s

Re: bookkeeper dev/sync meeting

It might be worth discussion the next release, who is going to be the release manager, important issues, etc. -Flavio > On 26 Oct 2016, at 00:50, Sijie Guo wrote: > > I setup a bi-weekly sync-up meeting on Thursday 8am-9am > https://goo.gl/6UZR1w > > We will start from this week (10/27/2016).

Jenkins build is back to normal : bookkeeper-master #1546

See

Re: bookkeeper dev/sync meeting

Great! I think I will join the meeting, do you mean that 8am at San Francisco TimeZone ? in Italy it will be 5 PM and it very good for me Thank you 2016-10-26 12:44 GMT+02:00 Flavio Junqueira : > It might be worth discussion the next release, who is going to be the release > manager, important

Re: [Discuss] 64 bits ledger id

Flavio, In theory you are right. But in practice it is virtually unique. RFC 4122 (https://www.ietf.org/rfc/rfc4122.txt) talks about multiple ways to generate virtually unique ID. Even in the sequence-id we have a theoretical chance of wrapping. So if we are worried about duplicates, we need a way

Re: bookkeeper dev/sync meeting

Yep it is 8 AM PT. We wanted to make it convenient for you too. :) Looking forward for it. Thanks, JV On Wed, Oct 26, 2016 at 8:28 AM, Enrico Olivelli wrote: > Great! > I think I will join the meeting, do you mean that 8am at San Francisco > TimeZone ? in Italy it will be 5 PM and it very good

Re: [Discuss] 64 bits ledger id

Agreed that the probability of collision is low, but it exists and there is no way to check if it kicks in if we don't have that information centralized. For wraparounds, we at least have a way of detecting that we reached the maximum value, but granted that if we reach the maximum value, then w

Re: [Discuss] 64 bits ledger id

On Tue, Oct 25, 2016 at 4:39 PM, Venkateswara Rao Jujjuri wrote: > We are using 64 bit ledger ids internally right now, but the ledger id is > supported by the application/caller. > We have extended Hierarchical ledger manger to Long hierarchical ledger > manger for this. > Can anyone from your

Re: bookkeeper dev/sync meeting

Ah, sorry, I forgot TimeZone. Yes, it is PDT. - Sijie On Wed, Oct 26, 2016 at 8:28 AM, Enrico Olivelli wrote: > Great! > I think I will join the meeting, do you mean that 8am at San Francisco > TimeZone ? in Italy it will be 5 PM and it very good for me > > Thank you > > > 2016-10-26 12:44 GMT+

Re: [Discuss] 64 bits ledger id

Right, we can still detect and handle collisions in either way, and in both methods (seq-long or uuid) it is extremely unlikely to see collision. But general assumption and practice is, lot of software built on the assumption that UUID will never have a collision. - Ledgers are unique across mult

Re: [Discuss] 64 bits ledger id

On Wed, Oct 26, 2016 at 11:45 AM Venkateswara Rao Jujjuri 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

[jira] [Commented] (BOOKKEEPER-959) ClientAuthProvider and BookieAuthProvider Public API used Protobuf Shaded classes

[ https://issues.apache.org/jira/browse/BOOKKEEPER-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15609938#comment-15609938 ] ASF GitHub Bot commented on BOOKKEEPER-959: --- Github user merlimat commented

Re: [Discuss] 64 bits ledger id

*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 fo

Re: [Discuss] 64 bits ledger id

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, Chara

Re: [Discuss] 64 bits ledger id

On Wed, Oct 26, 2016 at 3:49 PM, Matteo Merli 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 combin