Skip to content
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

SecureRandom.nextLong as node identifier #4

Open
lucianogreiner opened this issue Aug 12, 2021 · 3 comments
Open

SecureRandom.nextLong as node identifier #4

lucianogreiner opened this issue Aug 12, 2021 · 3 comments

Comments

@lucianogreiner
Copy link

Hello.

This is more like a question than an issue: Consider multiple independent services generating IDs on the same host/Mac address, how safe/unsafe is it to generate the node identifier for each service once at bootstrap with something like SecureRandom.nextLong?

Thanks a lot

@charithe
Copy link
Owner

Hi,

I am not an expert in this field so I can't give you a definite answer. I would probably be a bit cautious about random numbers as node identifiers unless it can be guaranteed that there won't be any duplicates. If your processes are independent, I assume they run on different JVMs as well. Consider, for example, what happens if two JVMs happen to start at the same time and SecureRandom is seeded with the same seed (I am just hypothesising here; I don't know how SecureRandom works internally. Maybe there's no chance of that happening due to hardware guarantees. See my disclaimer above about not being an expert). Then you'd end up with two processes having the same node identifier and increased probability of generating conflicting IDs.

It all comes down to how much you trust your node identifier generation process to produce unique identifiers. If the chances of a collision are miniscule, I don't see a problem with the approach you are suggesting.

BTW, this library is not actively maintained and I am not aware of anyone using it in production. Caveat emptor!

@lucianogreiner
Copy link
Author

Appreciate your answer. We have pretty much the same thoughts. We are actually enhancing the code a little bit to use atomics locks, quite similar to the Elasticsearch implementation to the same standard. We'll be happy to open a PR once we're done in case you're interested.

Thank you!

@charithe
Copy link
Owner

Sounds good! 👍🏽

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants