Hoss Man created SOLR-8849:
------------------------------
Summary: 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
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
