-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Will throw an exception if generating more than 65,535 flakes in a millisecond #2
Comments
@danielcompton I skimmed the code, but I'm not sure which exception you are talking about. Would you mind pointing it out? My thoughts on your note: Your suggestion sounds reasonable, but the current implementation sounds reasonable too. My guess is that if "overflow" happens, it probably is truly exceptional -- and an application would want to know about it and fail. The alternative is wait a millisecond -- but if you are making a system writing that many ID's, milliseconds may matter -- and you might end up with a backlog. Better to fail fast and let the application figure out what to do. P.S. Just as a reference, from http://boundary.com/blog/2012/01/12/flake-a-decentralized-k-ordered-unique-id-generator-in-erlang/
|
@xpe that exception doesn't happen in the code, I made it happen by simulating what would happen if we were to inc a flake which had Short/MAX_VALUE as it's sequence value. I agree 65,000 flakes/millisecond is a lot, it's equivalent to 65 million flakes/second. |
@danielcompton my feeling is, as @xpe mentioned, it's better to allow the application to decide how to handle this situation. |
@maxcountryman is it worth documenting it as an extremely unlikely edge case then? |
Sure, more documentation couldn't hurt. |
While it is very unlikely to happen, if 65,535 flakes are generated in a millisecond, then an exception will be thrown. Would it be better to check this and wait until the start of the next millisecond to generate the next flake?
I'm not 100% sure this is even an issue, if the caller is aware that this may throw an exception then they could prepare for it and catch it to retry.
The text was updated successfully, but these errors were encountered: