I think david is just running into a situation were his test fail sometimes with random seeds but always if he forces RAMDirectory no matter what seed. He is asking for advice if there are any traps with ram dir in randomized testing...
maybe that helps @David S.: why don't you paste a patch that we can help here? simon On Sat, Apr 6, 2013 at 8:35 PM, Dawid Weiss <dawid.we...@cs.put.poznan.pl> wrote: > I still don't get what it is that you're after, David. > > If you stumbled upon an execution path that (with a given seed) > reproduces the error you can isolate this path and create a test that > doesn't have any randomness anymore. If you only need it for temporary > debugging, pass -Dtests.seed and provide the seed that reproduces the > issue. > > If your intent is to always run a given class with the same seed, you > can do this by adding @Seed at the suite (test class) level -- this > will fix the seed for that particular class. Unfortunately this does > *not* mean you're fixing the execution paths forever because if > somebody changes some random choices in a later refactoring or even > adds something that consumes more (or less) random numbers from the > generator then your implementation will also be affected, regardless > of the fixed seed it uses. > > Dawid > > On Sat, Apr 6, 2013 at 8:28 PM, David Smiley (@MITRE.org) > <dsmi...@mitre.org> wrote: >> I need a seed to ensure that my test, which uses a lot of randomization, >> generates the right randomized shapes. This particular seed just so happens >> to pick RAMDirectory as well, and that's how I first stumbled upon the >> problem; all the circumstances were just right. I'm not manually using "new >> RAMDirectory()", I'm letting it get chosen either by default or if I want >> something else then picking it via the system property -- "newDirectory()". >> I am aware of the complexities of debugging this by inadvertently altering >> what the random seed is at any given moment due to commenting out something >> in an attempt to deduce what the problem is. I don't think I fell victim to >> that trap because I've been watchful at the moment the assertion occurs, >> what the particular random indexed & queried shapes should be. >> >> ~ David >> >> >> Michael McCandless-2 wrote >>> Is it a particular seed that shows the failure with RAMDir? >>> >>> If so, I think most likely by specifying the directory to ant you are >>> effectively altering the random seed? >>> >>> If that's it, you can go into LuceneTestCase.java where it has this >>> directory logic and keep consuming the randomness but then hardwire >>> the directory impl you want? Be sure to put a // nocommit there too >>> ;) >>> >>> Mike McCandless >>> >>> http://blog.mikemccandless.com >>> >>> On Sat, Apr 6, 2013 at 2:09 PM, David Smiley (@MITRE.org) >>> < >> >>> DSMILEY@ >> >>> > wrote: >>>> I've been reworking a randomized test in Lucene spatial; it's pretty >>>> hard. >>>> One particular failing test is driving me crazy right now. I figured out >>>> that the problem would only occur if the RAMDirectory was chosen, and of >>>> course if I created just the right sequence of indexed shapes and query >>>> for >>>> the right shape, etc... so there's a lot of things that have to be just >>>> so >>>> for the test to fail. If the *only* thing I change is >>>> -Dtests.directory=RAMDirectory then it fails absolutely every time at the >>>> same spot, and if the directory is something else because I set it with >>>> the >>>> system property, then the test passes. Could this actually be a bug in >>>> my >>>> code? Any tips on how to debug this is highly appreciated. I can change >>>> the codec but that doesn't affect the problem. I was hoping to use >>>> SimpleText codec but I can't easily view the contents of the RAMDirectory >>>> :-) >>>> >>>> All of the code in question is local but if it would help I can post a >>>> patch >>>> some where. I haven't narrowed down the problem exactly so it requires >>>> setting the random seed. >>>> >>>> ~ David >>>> >>>> >>>> >>>> ----- >>>> Author: >>>> http://www.packtpub.com/apache-solr-3-enterprise-search-server/book >>>> -- >>>> View this message in context: >>>> http://lucene.472066.n3.nabble.com/Possible-problem-with-RAMDirectory-tips-please-tp4054241.html >>>> Sent from the Lucene - Java Developer mailing list archive at Nabble.com. >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: >> >>> dev-unsubscribe@.apache >> >>>> For additional commands, e-mail: >> >>> dev-help@.apache >> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: >> >>> dev-unsubscribe@.apache >> >>> For additional commands, e-mail: >> >>> dev-help@.apache >> >> >> >> >> >> ----- >> Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book >> -- >> View this message in context: >> http://lucene.472066.n3.nabble.com/Possible-problem-with-RAMDirectory-tips-please-tp4054241p4054245.html >> Sent from the Lucene - Java Developer mailing list archive at Nabble.com. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
