Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-22 Thread Max Countryman
> On Jun 22, 2016, at 06:27, Bruno Bonacci wrote: > > @Brian, The clock drift problem was in answer to your question and generally > it was referring to the pure System/currentTimeMillis implementation. The > System/nanoTime, as it is now, is completely broken as it offsets against the > wall

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-22 Thread Bruno Bonacci
On Wed, Jun 22, 2016 at 2:17 PM, Brian Platz wrote: > > > On Wednesday, June 22, 2016 at 7:25:50 AM UTC-4, Bruno Bonacci wrote: >> >> >> To answer Brian on the "potential" problem of the clock drift I would >> recommend to have a look to >> https://aphyr.com/posts/299-the-trouble-with-timestamps.

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-22 Thread Brian Platz
On Wednesday, June 22, 2016 at 7:25:50 AM UTC-4, Bruno Bonacci wrote: > > > To answer Brian on the "potential" problem of the clock drift I would > recommend to have a look to > https://aphyr.com/posts/299-the-trouble-with-timestamps. Beside the > hardware problems you have to account for thin

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-22 Thread Bruno Bonacci
Hi, Yes adding more bits to the id is certainly undesirable, however it isn't uncommon. For example Linked just published a paper on Ambry a distributed datastore which uses a total of *40 bytes* to identify a blob (8 bytes for the partition + 32 bytes for UUID, see: http://dprg.cs.uiuc.edu/docs/S

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-21 Thread Max Countryman
I also released Flake 0.4.2 today which includes an important bugfix where two competing threads could have caused duplicate IDs in certain circumstances as well as a new method for deriving timestamps. > On Jun 21, 2016, at 16:29, Max Countryman wrote: > > Brian, > > I think you make good p

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-21 Thread Max Countryman
Brian, I think you make good points here, especially with regard to the size of IDs. I’d also like to point out that while adding the process and thread IDs helps, it doesn’t eliminate the possibility of duplicate IDs: this is why it’s necessary to write out the last used timestamp in a separat

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-21 Thread Brian Platz
Bruno, I think the more you can reduce the chance of collision the better and the thread-local capability is a good idea, but in the process you've almost doubled the bits. For me anyhow, an ID need to be produceable at a reasonable rate (1 million a second per machine is good for me), have ne

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-21 Thread Bruno Bonacci
Sorry, it looks like images are only visible in the google groups https://groups.google.com/forum/#!topic/clojure/fRYCowf6VUg Bruno On Tue, Jun 21, 2016 at 1:38 PM, Bruno Bonacci wrote: > >

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-21 Thread Bruno Bonacci
> > Another thing I've noticed is that you are using (System/currentTimeMillis > ) to get the wall clock on every generation. > > (S

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-17 Thread Max Countryman
Hi Bruno, > On Jun 17, 2016, at 03:49, Bruno Bonacci wrote: > > Hi Max, > > That's a interesting library thanks. > > Does the library guarantee monotonically increasing IDs? Eg protection > against clock reset and other clock fluctuations? Like the Erlang implementation, Flake asks the user

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-17 Thread Bruno Bonacci
Hi Max, That's a interesting library thanks. Does the library guarantee monotonically increasing IDs? Eg protection against clock reset and other clock fluctuations? Another thing I've noticed is that you are using (System/currentTimeMillis) to get the wall clock on every generation. (System/

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-16 Thread Max Countryman
Hi again Mark, I set up some basic micro-benchmarks out of curiosity. Full disclosure, I’m not entirely sure I’m using criterium correctly here, but the results on my machine

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-03 Thread Max Countryman
Hi again, I just released flake 0.4.1, containing a bugfix where `timer/read-timestamp` would throw an uncaught exception when the provided path did not exist. Thanks, Max > On Jun 2, 2016, at 18:03, Max Countryman wrote: > > Hi, > > I’m happy to announce a new release of Flake, the decent

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-03 Thread Max Countryman
Hi Mark, I haven’t done any benchmarking comparing Flakes to UUIDs. However the primary benefit of flake IDs, over a traditional UUID, e.g. UUID-1, is flakes do not require coordination (i.e. to avoid clock-skew and duplicate IDs), provide k-ordering (UUID-1’s bit ordering breaks this), and use

Re: [ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-02 Thread Mark Engelberg
This is interesting. Is it faster than uuid for generation and/or comparing for equality? On Thu, Jun 2, 2016 at 6:03 PM, Max Countryman wrote: > Hi, > > I’m happy to announce a new release of Flake, the decentralized, k-ordered > unique ID generator. > > Flake 0.4.0 includes a number of import

[ANN] Flake 0.4.0: Decentralized, k-ordered unique ID generator

2016-06-02 Thread Max Countryman
Hi, I’m happy to announce a new release of Flake, the decentralized, k-ordered unique ID generator. Flake 0.4.0 includes a number of important breaking changes, but by far the most important is dropping `generate` in favor of `generate!` which now returns a ByteBuffer. Previously `generate` re