stephenc / eaio-uuid Goto Github PK
View Code? Open in Web Editor NEWFork of eaio-uuid
Home Page: http://stephenc.github.com/eaio-uuid/
License: Other
Fork of eaio-uuid
Home Page: http://stephenc.github.com/eaio-uuid/
License: Other
can this be updated to 3.3?
UUID relies on org.omg.CORBA.portable.IDLEntity which is no longer resolved by default in JDK9 modular system and it is likely to be removed completely in JDK11.
Right now, the workaround is to manually add the java.corba module by the --add-modules command line parameter.
Another option, is to add the CORBA standalone dependency to the project where UUID is used.
It would be nice to have a proper fix for newer Java versions.
Hi Stephen,
any chance we could merge this repo into this: https://github.com/johannburkard/UUID
Thanks,
Johann
First off, eaio-uuid could possibly be the best Java UUID library out there. That said, I found a couple of somewhat related issues with it for my usecase:
Background: I have bunch of event streams that I need to migrate from one database to another. Each stream consists of events with auto increment IDs:
Since the new storage solution is more a distributed one I intend to migrate the auto increment IDs to UUIDs. The end goal will be:
To be able to generate these UUIDs I had a look at UUIDGen#createTime(...)
which at first looked like a perfect fit. However;
Problem: The UUIDGen#createTime(...)
implementation only works for correctly for ascending consecutive input of currentTimeMillis
. As soon as a descending currentTimeMillis
is put in, the next time generated will be increased by 100 nanoseconds. That is a bug.
In my case this means that I need to sort all my events globally by timestamp to correctly generate UUIDs of type 1. Since my data is too big for a single instance to handle, this is impossible. Restarting the JVM for every stream :-) is neither an option.
While UUIDGen#createTime(...)
is thread-safe per se (it uses AtomicLong
for synchronization), a related problem is that of multiple threads calling UUIDGen#createTime(...)
. Since they generally will have a different notion of time (especially in my case where time is not Thread.currentTimeMillis()
) the implementation is inherently broken. This boils down to singleton state;
If it wasn't for the fact that lastTime
and UUIDGen#createTime(...)
were static, this would not be a problem. In that case, I'd be able to instantiate one UUIDGen
per migration thread, sorting my stream individually and then generating UUID using strictly monotonical input to UUIDGen#createTime(...)
.
Proposed solution:
UUIDGen
, call it ReusableUUIDGen
or something, that supports reuse with non-singleton state.UUIDGen
simply hold a singleton ReusableUUIDGen
instance and proxy calls to it.UUIDGen#createTime(...)
the if
statement in the while
loop to properly support decreasing input to the method.UUIDGen#createTime(...)
only works for consecutive larger input.The above solution has the benefit of being a backward compatible implementation while still enabling reusing the UUIDGen
.
Workaround:
UUIDGen#createTime(0)
call before calling the static method with a descending value.Related:
Hello Stephen,
I was looking at your implementation of the version 1 (time-based) UUID and I had a read of the RFC4122.
I was interested in using your library but I think it still requires some work (at the moment I can't help you with it I am sorry).
My idea was to keep the other two "shared state" described below in memory (with the possibility to store it to disk) together with what you already have:
From a system-wide shared stable store (e.g., a file), read the
UUID generator state: the values of the timestamp, clock sequence,
and node ID used to generate the last UUID.
So three fields instead of one. It would be great to have the possibility to completely skip the MAC polling and get a pseudo-random sequence as described below:
The exact algorithm to generate a node ID using these data is system
specific, because both the data available and the functions to obtain
them are often very system specific. A generic approach, however, is
to accumulate as many sources as possible into a buffer, use a
message digest such as MD5 [4] or SHA-1 [8], take an arbitrary 6
bytes from the hash value, and set the multicast bit as described
above.
Where the sources
could be passed in by clients.
I had a quick peek at your UUIDGen and it looks like you merge Node ID and clockSeqAndNode (line 194). Maybe I am not reading it right...
Ok, let me know what you think...
I may have a vision problem but it looks like the grabbag dependency is not needed by uuid… no?
One utility class is already included: Hex, and given the amount of things in grabbag and only Resource being used i think it makes sense.
By not including com.eaio.util.Resource you required a 75Kb dependency for a 13Kb library!! :-(
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.