lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Commented: (LUCENE-1791) Enhance QueryUtils and CheckHIts to wrap everything they check in MultiReader/MultiSearcher
Date Wed, 12 Aug 2009 22:00:15 GMT


Hoss Man commented on LUCENE-1791:

bq. I'm guess the NAN failures are not a problem - looks like they fail because NAN != NAN?

right -- but why would the scores be NaN when wrapped in a MultiReader? when it's *not* wrapped
in a MultiReader the test passes, so the scores must not be NaN in that case.

bq. I don't think the fieldcache insanity is multi-reader related [...] same stuff now, doubled

The sanity checker ignores when two CacheEntries differ only by parser (precisely because
of the the null/default parser issue) and the resulting value object is the same.  but it
does include all related CacheEntry objects in an Insanity object so that you have them all
for debugging.

Looking at TestCustomScoreQuery.testCustomScoreByte (for example)...

*** BEGIN Insane
FieldCache usage(s) ***
SUBREADER: Found caches for decendents of org.apache.lucene.index.DirectoryReader@88d2ae+iii
	'org.apache.lucene.index.DirectoryReader@88d2ae'=>'iii',byte,null=>[B#841343 (size
=~ 33 bytes)
(size =~ 33 bytes)
(size =~ 33 bytes)
(size =~ 33 bytes)

*** END Insane
FieldCache usage(s) ***


The insanity type is "SUBREADER", so it's specificly identified a problem with that type of
relationship.  There are 4 CacheEntries listed in the error all from the same field, but from
two different readers.  If you note the value identity hashcodes (just before the size estimate)
each reader has only one value cached for that field (with different parsers) which is why
there isn't a seperate error about the multiple values. 
as the first line of hte Instanity.toString() states: what it found is that DirectoryReader@88d2ae
and at least one of it's decendents both have cached entires for the same field.

> Enhance QueryUtils and CheckHIts to wrap everything they check in MultiReader/MultiSearcher
> -------------------------------------------------------------------------------------------
>                 Key: LUCENE-1791
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Test
>            Reporter: Hoss Man
>             Fix For: 2.9
>         Attachments: LUCENE-1791.patch
> methods in CheckHits & QueryUtils are in a good position to take any Searcher they
are given and not only test it, but also test MultiReader & MultiSearcher constructs built
around them

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message