lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-6292) seed StringHelper better
Date Tue, 24 Feb 2015 23:28:05 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message