[
https://issues.apache.org/jira/browse/LUCENE-3986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss resolved LUCENE-3986.
---------------------------------
Resolution: Not A Problem
Fix Version/s: (was: Trunk)
I don't think this is a problem in practice.
Tests that do very heavy random ops should fork their own local random anyway,
with a randomized seed. This requires explicit ThreadLocalRandom anyway because
Random has a synchronized method.
If we returned a non-coordinated Random from the randomizedtesting package the
only thing it would tell us is that something failed (the failure wouldn't be
reproducible). I don't want to integrate this into the library, it opens a lot
of abuse use cases.
> Support running tests with a simple, non-asserting (and possibly shared)
> Random
> -------------------------------------------------------------------------------
>
> Key: LUCENE-3986
> URL: https://issues.apache.org/jira/browse/LUCENE-3986
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/test
> Reporter: Dawid Weiss
> Assignee: Dawid Weiss
> Priority: Minor
>
> Robert asked for it. Calling random() (and its methods) can obscure memory
> visibility issues (because random() is thread local, context-sensitive,
> etc.). An option (or randomly selected mode) of running with a simple Random
> (static/ test method level only) would simulate the framework as it was
> before (reading -- possibly non-reproducible thread races but at the same
> time testing memory visibility issues in the core code).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
