[ https://issues.apache.org/jira/browse/SOLR-8849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man updated SOLR-8849: --------------------------- Attachment: SOLR-8849.patch proposed patch. in addition to cleaning up the random usage, this also refactors the non-loop/sleep portions of the monkeyThread into a new {{public void causeSomeChaos()}} method. this way, it's possible to write a (single threaded) test with 100% reproducible chaos w/o needing to write your own random decision making about what chaos methods to call. > 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 > Attachments: SOLR-8849.patch > > > 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