[
https://issues.apache.org/jira/browse/SOLR-8849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man reassigned SOLR-8849:
------------------------------
Assignee: Hoss Man
i'm happy to work on this, but before i spend any time on it i'd appreciate if
[~markrmil...@gmail.com] or someone else equally familiar with ChaosMonkey
could sanity check my assessment (i can't imagine the current behavior is
intentionally desired, but it also seems like it would have been totally
obvious when initially written this way, so i'm not sure why it wasn't caught
then)
> ChaosMonkey should cuase chaos in a more reproducible manner
> ------------------------------------------------------------
>
> Key: SOLR-8849
> URL: https://issues.apache.org/jira/browse/SOLR-8849
> Project: Solr
> Issue Type: Test
> Reporter: Hoss Man
> Assignee: Hoss Man
>
> Looking into the ChaosMonkey code a bit, and it seems like this class --
> particularly the way {{monkeyThread}} is defined -- uses randomness in a way
> that makes it extremely unlikely that it will ever create reproducible
> failures.
> Obviously in any test where there are multiple concurrent threads, timing
> issues might prevent test reproducibility -- but in this case, even the
> sequence of "chaos" actions the monkeyThread takes won't be reproducible if
> anyother concurrent test thread accesses {{LuceneTestCase.random()}} ...
> {code}
> public void run() {
> while (!stop) {
> try {
>
> Random random = LuceneTestCase.random();
> // ... lots of stuff using random, or calling methods that use
> LuceneTestCase.random() directly
> {code}
> It seems like it would be a lot better if ChaosMonkey's constructor created
> it's own private {{Random chaosRand}} using {{LuceneTestCase.random()}} as a
> seed, and then used {{chaosRand}} to make all random choices in it's methods.
> That way at least the sequence of chaotic operations made by ChaosMonkey
> would be consistent for a given test seed, even if the exact
> timing/interleaving of those operations relative to other operations by other
> threads couldn't be garunteed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
