Currently there is a chance of collision if multiple Java processes on the same machine are using DataStax Java Driver to generate UUIDs. This is because the hash in UUIDs.makeNode() (https://github.com/datastax/java-driver/blob/2.1/driver-core/src/main/java/com/datastax/driver/core/utils/UUIDs.java#L88) doesn't include any process information, such as PID. A simple fix would be to append the value of ManagementFactory.getRuntimeMXBean().getName() to the hash too.
The driver now tries various methods to include the PID in the hash, look at the javadocs of UUIDs for the detailed description.
can you guys double check in the other drivers? thanks
thank you for your initial patch. There has been indeed some discussion about how to properly obtain the PID.
First of all, as pointed out in your initial pull request, Sigar is too heavyweight for the Java driver and its binaries do not seem to be up-to-date in Maven Central.
Secondly, thanks to JAVA-727, the driver can now use JNR when available.
So my suggestion here is to try the following methods one by one, in the order they are listed below:
If the System property com.datastax.driver.PID is set then the value to use as a PID will be read from that property;
Otherwise, if a native call to getpid() is possible, then the PID will be read from that call;
Otherwise, an attempt will be made to read the PID from JMX's RuntimeMXBean name, which is a well-known, yet undocumented "hack";
If all of the above methods fail, a random integer will be generated and used as a surrogate PID.