SecureRandom.nextLong as node identifier

[lucianogreiner]

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]

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]

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]

Sounds good! 👍🏽