Yonik and Mike,
It seems to happen when you facet and group.
What do you suggest I do? Should the code change to switch to one or the
other mode when
we are using facet=true and group=true?
For the test to work without erroring, shall I just added:
} finally {
If possible (but it may be hard here since you don't have direct
acces...) it's better to purge only the readers you know are expected
to have caused insanity?
Otherwise you could mask a real problem.
FieldCache insanity is bad, so, when it's caused we need to make sure
we understand the root
I am not sure how I am going to get a handle for that...
Most of the other test cases do it this way when dealing with grouping...
FieldCache.DEFAULT.purgeAllCaches()
On 7/9/11 5:16 AM, Michael McCandless luc...@mikemccandless.com wrote:
If possible (but it may be hard here since you don't
You can purge entries from the field cache before your test finishes?
Ie call FieldCache.DEFAULT.purge(IR).
The problem is that will mask any real problems where insanity is
unexpectedly being created.
Or, maybe switch test over to using per-segment faceting? Then (I
think?) no insanity should
On Thu, Jun 30, 2011 at 11:58 PM, Bill Bell billnb...@gmail.com wrote:
I meant FC insanity. It does not appear to be an NPE.
That's natural, and not a bug. Grouping always uses per-segment field
cache entries, where faceting sometimes uses top level field caches.
-Yonik
I meant FC insanity. It does not appear to be an NPE.
I have a test case that shows it in SOLR-2242.
Simon may be looking at it also.
On 6/28/11 6:44 AM, Michael McCandless luc...@mikemccandless.com wrote:
Hi Bill,
Can you open an issue and make a patch showing the problem? Thanks.
The
Hi Bill,
Can you open an issue and make a patch showing the problem? Thanks.
The test is failing only from the FC insanity? Or is there another
exception (you mentioned NPE but I don't see it).
Mike
Mike McCandless
http://blog.mikemccandless.com
On Mon, Jun 27, 2011 at 11:59 PM, Bill Bell
