linux - Repeated set of UUIDs from java's UUID.randomUUID() -

we have observed set of 200,000 uuids has replayed 2 months apart, , i'm wondering if has seen similar.

the uuids generated using uuid.randomuuid(). in digging (looking @ java source), randomuuid() uses securerandom() under hood, in turn using nativeprng. understanding nativeprng uses /dev/urandom acquire seed. implication of course baffling - somehow /dev/urandom returned same seed nativeprng 2 months apart. can tell, once instantiated prng not re-seed. long running job s listening messages , using uuid id it. pseudocode simply:

< receive message> string uuid = uuid.randomuuid().tostring(); string fname = h.composeartifact(uuid);

the os centos 6, on aws ec2 instance running jdk1.6. has seen/experienced in past? seems kind of thing should 'never happen'...

from jdk 1.6 source, indeed, uuid.randomuuid() feeds on java.util.securerandom instance. if got repeated sequence of uuid, either got lucky (or unlucky, depending on point of view), or played vm snapshots, or there fishy in java configuration.

when taking vm snapshot, record complete live state of machine, processes , ram included. if there live process instantiated securerandom instance, restoring snapshot bring state, sequence of random values output securerandom same each time restore occurs, until securerandom reseeds /dev/urandom (/dev/urandom continuously gathers "random" physical events, these won't impact securerandom state until next reseeding).

the java configuration may impact securerandom, in securerandom not prng, shell around instance of securerandomspi provided duly registered cryptographic provider. sun's jdk comes default implementation normally feeds on system's resources (/dev/urandom on linux). however, can configured; lookup java.security.egd system property, , securerandom.source property in java.security file. default provider may replaced altogether alternate implementation things differently (and possibly poorly). see this answer details. verifying random source indeed used can bit complex, try launching process strace, show system calls, hence whether /dev/random or /dev/urandom opened @ point.

if java configuration fine, and there no game vm snapshots, and sure indeed got same sequence of uuid previously, really should have bought powerball ticket instead (but not believe in scenario).