You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "David Smiley (@MITRE.org)" <DS...@mitre.org> on 2013/04/06 20:09:48 UTC
Possible problem with RAMDirectory; tips please
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@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Possible problem with RAMDirectory; tips please
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
> 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
I don't think I follow you. RAMDirectory will be picked eventually
with some seed. What is the problem -- you can't get it to pick
RAMDirectory?
D.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Possible problem with RAMDirectory; tips please
Posted by "Smiley, David W." <ds...@mitre.org>.
On 4/8/13 5:05 PM, "Dawid Weiss" <da...@cs.put.poznan.pl> wrote:
>> thought I checked for that but apparently I got confused. I do find it
>> disconcerting that the random seed can get incremented by
>> LuceneTestCase.newDirectory() a different number of times depending on
>> wether or not -Dtests.seed has been set.
>
>It's not really like that. By passing -Dtests.seed you're not "just"
>incrementing/ changing the random generator. You're starting from a
>different seed so you're running a whole different execution scenario.
>Think of it as Heisenberg's uncertainty principle -- if you've touched
>something on the lab plate (anything) then the outcome will be
>different.
>
>If you want your test to pick a random directory but make this choice
>insensitive to tests.seed then use the newDirectory(Random) method
>with a "forked" random number generator. As in here:
>
>Random forkedRandom = new Random(random().nextLong());
>Directory myDirectory = LuceneTestCase.newDirectory(forkedRandom);
>
>then you can change "myDirectory" to your liking and it won't affect
>the default random generator...
>
>Random forkedRandom = new Random(random().nextLong());
>// you don't even need to call newDirectory(forkedRandom) but I'll keep
>it here.
>Directory myDirectory = LuceneTestCase.newDirectory(forkedRandom);
>// temporarily substitute with something else...
>myDirectory = ...;
I understand what you're saying and how it works today, and it isn't
really surprising in hindsight. Of course I could use my own random but
then if I do so, I forgo all the convenience code in LuceneTestCase that
depend on random(), and you can't really blame me for using those nice
convenience methods. The specific circumstance in which I set
-Dtests.directory is that I wanted to use SimpleFSDirectory so that I
could also use SimpleTextCodec so that I could inspect what Lucene was
storing. Boom, I did this and my whole test is testing something
different than what I wanted to. Your suggestion is that I modify my
tests, which are already using extensive randomization, to not use all the
convenience methods, I'm using. Sure it's possible but... :-( Again,
the status quo is not surprising (in hindsight), it's not a bug or
deficiency (I rescind my use of the word "disconcerting"), but it would be
nice if it was easier for me to pick different Lucene infrastructure
components via system properties without affecting the random state.
One potential way to accomplish the goal that would be less jarring to the
existing code is to have LuceneTestCase's convenience methods use a
different random() -- say internalRandom() that is based off of a copy of
random() initialized at the start of the test. Just an idea.
~ David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Possible problem with RAMDirectory; tips please
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
> thought I checked for that but apparently I got confused. I do find it
> disconcerting that the random seed can get incremented by
> LuceneTestCase.newDirectory() a different number of times depending on
> wether or not -Dtests.seed has been set.
It's not really like that. By passing -Dtests.seed you're not "just"
incrementing/ changing the random generator. You're starting from a
different seed so you're running a whole different execution scenario.
Think of it as Heisenberg's uncertainty principle -- if you've touched
something on the lab plate (anything) then the outcome will be
different.
If you want your test to pick a random directory but make this choice
insensitive to tests.seed then use the newDirectory(Random) method
with a "forked" random number generator. As in here:
Random forkedRandom = new Random(random().nextLong());
Directory myDirectory = LuceneTestCase.newDirectory(forkedRandom);
then you can change "myDirectory" to your liking and it won't affect
the default random generator...
Random forkedRandom = new Random(random().nextLong());
// you don't even need to call newDirectory(forkedRandom) but I'll keep it here.
Directory myDirectory = LuceneTestCase.newDirectory(forkedRandom);
// temporarily substitute with something else...
myDirectory = ...;
> test that uses randomization to "just" change the directory for a given test
> run (i.e. for a given seed). It would be nice if there was a mechanism to
> restore the random state so you could restore it from when it was captured
> at the beginning of a method call. This wouldn't just apply to
> newDirectory() but to some other similar utility methods.
I'm sorry but I don't see the advantage of that. You're trying to do
something for which better alternatives exist, as explained above. If
your code wants to make certain branch/ logic independent of the
default randomness you can just use your own Random instance (seeded
with a constant or whatever else that comes to your mind or is helpful
in the context).
Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Possible problem with RAMDirectory; tips please
Posted by "David Smiley (@MITRE.org)" <DS...@mitre.org>.
Thanks for that tip Dawid. I'll consider AspectJ some day; that's an
interesting approach.
So as it turns out, I was wrong when I said that the same shapes etc. were
being tested when I switched the directory via the system property. I
thought I checked for that but apparently I got confused. I do find it
disconcerting that the random seed can get incremented by
LuceneTestCase.newDirectory() a different number of times depending on
wether or not -Dtests.seed has been set. This makes it difficult to make a
test that uses randomization to "just" change the directory for a given test
run (i.e. for a given seed). It would be nice if there was a mechanism to
restore the random state so you could restore it from when it was captured
at the beginning of a method call. This wouldn't just apply to
newDirectory() but to some other similar utility methods.
~ 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-tp4054241p4054565.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Possible problem with RAMDirectory; tips please
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
Ok, thanks.
What I do in such circumstances is apply an aspect (aspectj) that logs
(for every thread) every entry/exit from a block of code I'm
interested in (package, class, etc.) and then run the two differing
configurations. Then I simply diff the outputs using Araxis Merge --
this is typically enough to tell what execution paths are different
and lets you set up a trap to analyze the problem at its source
(diverging paths).
Yes, it requires some aspectj expertise and getting to know this may
exceed what you need :) Create an issue though and provide a patch,
perhaps me or somebody else will know what's going on.
Dawid
On Sat, Apr 6, 2013 at 9:03 PM, David Smiley (@MITRE.org)
<DS...@mitre.org> wrote:
> I'll try to make a version of the test that is unrandomized -- I'll index the
> exact shapes needed and query for the specific shape using the right
> algorithm. And at that point, I'll try and reduce it. Simon's right; I'm
> looking for debugging tips/strategy advise. I find it pretty odd that my
> test will fail for a particular directory but not others (in the right
> circumstances -- i.e. the specific shapes etc.). That is suspicious -- it
> has me wondering if the bug is perhaps not in my code after all since I
> don't know what my code (or anyone's Lucene code for that matter) could
> possibly be doing that would make the outcome dependent on the directory
> implementation.
>
> ~ 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-tp4054241p4054250.html
> Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Possible problem with RAMDirectory; tips please
Posted by Chris Hostetter <ho...@fucit.org>.
: I'll try to make a version of the test that is unrandomized -- I'll index the
or just create a jira with...
* a patch
* the branch/revision you applied that patch to ("svnversion" output)
* cut/paste the failure stack trace & reproduce line that you get showing
the failing seed
* details of the jvm you are testing
...then we can see if other people can reproduce consistently, and if
anyone has any idea what it is about your test or RAMDir that would cause
this failure.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Possible problem with RAMDirectory; tips please
Posted by "David Smiley (@MITRE.org)" <DS...@mitre.org>.
I'll try to make a version of the test that is unrandomized -- I'll index the
exact shapes needed and query for the specific shape using the right
algorithm. And at that point, I'll try and reduce it. Simon's right; I'm
looking for debugging tips/strategy advise. I find it pretty odd that my
test will fail for a particular directory but not others (in the right
circumstances -- i.e. the specific shapes etc.). That is suspicious -- it
has me wondering if the bug is perhaps not in my code after all since I
don't know what my code (or anyone's Lucene code for that matter) could
possibly be doing that would make the outcome dependent on the directory
implementation.
~ 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-tp4054241p4054250.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Possible problem with RAMDirectory; tips please
Posted by Simon Willnauer <si...@gmail.com>.
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
<da...@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)
> <DS...@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Possible problem with RAMDirectory; tips please
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
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)
<DS...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Possible problem with RAMDirectory; tips please
Posted by "David Smiley (@MITRE.org)" <DS...@mitre.org>.
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Possible problem with RAMDirectory; tips please
Posted by Michael McCandless <lu...@mikemccandless.com>.
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)
<DS...@mitre.org> 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@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org