[
https://issues.apache.org/jira/browse/LUCENE-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742600#action_12742600
]
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 entry.
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)...
{code}
*** BEGIN
org.apache.lucene.search.function.TestCustomScoreQuery.testCustomScoreByte:
Insane FieldCache usage(s) ***
SUBREADER: Found caches for decendents of
org.apache.lucene.index.directoryrea...@88d2ae+iii
'org.apache.lucene.index.directoryrea...@88d2ae'=>'iii',byte,null=>[B#841343
(size =~ 33 bytes)
'org.apache.lucene.index.directoryrea...@88d2ae'=>'iii',byte,org.apache.lucene.search.FieldCache.DEFAULT_BYTE_PARSER=>[B#841343
(size =~ 33 bytes)
'org.apache.lucene.index.compoundfilereader$csindexin...@77daaa'=>'iii',byte,org.apache.lucene.search.FieldCache.DEFAULT_BYTE_PARSER=>[B#981898
(size =~ 33 bytes)
'org.apache.lucene.index.compoundfilereader$csindexin...@77daaa'=>'iii',byte,null=>[B#981898
(size =~ 33 bytes)
*** END
org.apache.lucene.search.function.TestCustomScoreQuery.testCustomScoreByte:
Insane FieldCache usage(s) ***
{code}
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
directoryrea...@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: https://issues.apache.org/jira/browse/LUCENE-1791
> 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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
