: Ok, I expected something like this. Why are some test timing related? Are there any informations about this.
multi-threaded code. In the extreme case, Test falures may be timing related due to buggy race conditions between multiple threads in "real code" (ie: very problematic for end users). More typically what we see is race conditions between a thread in "real code" and a thread in "test code" (ie: a badly written test that doesn't harm any production user but is anoying to track down). Timing factors betwen machines can also cause reproducibility problems in randomization logic -- the test framework tries to ensure every thread get's it's own consistent 'Random', but if there are multiple test threads that both interact with something (ie: a single SolrCore in a stress test), the order those threads are scheduled by the VM determines the order that the random values from each of those threads come into play -- ie: the order that 2 diff (random) updates from 2 diff threads hit solr, potentially triggering a bug in some situations (ie: maybe a certain ordering of updates). other example of how "timing" can cause reproducibility problems is in unpredictible ordering in lists which are then used to select things at random... Example: maybe there is a bug with shutting down nodes that only manifests if the "leader" replica of a collection is being shutdown -- a (correctly written) test that might be garunteed that the seed DEADBEEF will cause it to always spin up exact 5 nodes and shutdown the 2nd node in the list -- but thread scheduling during collection creation may cause the 1st node in the list to _usually_ host the leader, but on rare occasion that 2nd node might host the leader because of which thread joined the election first. ...these are just some examples off the top of my head based on years of experience reading test logs ... and that's before we even talk about the possiblity/anoyance of actual race conditions/deadlocks in code, that might only trigger on slow machines (or fast machines) based on thread scheduling ... assuming we even have a test that causes those particular threads to try and run at the same time :) -Hoss http://www.lucidworks.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
