[
https://issues.apache.org/jira/browse/LUCENE-6292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14335655#comment-14335655
]
Hoss Man commented on LUCENE-6292:
----------------------------------
i never realized this "psuedo-randomness" id generating code existed until
today ... it definitely seems like it could easily contributed to hard to
reproduce test failures between multiple machines -- but if i'm reading this
right, at least prior to this patch the same JVM, with the same command line
args _should_ produce a consistent sequence of ids .... correct?
But with this patch even that level of "same machine, same JVM args"
reproducibility goes away doesn't it?
would be be worthwhile to make this static init code try, as a first attempt,
to read the "tests.seed" system property, and if it's set then use a hashcode
of that string to seed everything else (superceeding /dev/urandom, the
sysprops, nanoTime, etc...)
Wouldn't that give us best of all worlds: more (reproducible) randomness in
JVMs running tests, and more randomness in non-test applications.
> seed StringHelper better
> ------------------------
>
> Key: LUCENE-6292
> URL: https://issues.apache.org/jira/browse/LUCENE-6292
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Attachments: LUCENE-6292.patch
>
>
> The current code is good, it avoids SecureRandom/blocking when we don't need
> real security (just used for safety checks).
> On the other hand it has some downsides:
> * the sources of randomness here aren't the best, e.g. sysprops will be the
> same when using automated deployment tools if the jvm is the same version,
> installed in the same place, same user, etc.
> * asking for a Properties of all the sysprops needs blanket read-write access
> to all of them, which is inconvenient if you want to lock this down in tests
> (which I do). Today this means you can't ban write access or lucene won't
> work.
> I think we should use /dev/urandom when its available, its just practical and
> exactly what we need. If its not available (e.g. windows) we can use the
> current logic. If sysprops arent available we can just use another hashcode
> instead and lucene can still be used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
