You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2016/03/15 00:31:33 UTC

[jira] [Assigned] (SOLR-8849) ChaosMonkey should cuase chaos in a more reproducible manner

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