[
https://issues.apache.org/jira/browse/LUCENE-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated LUCENE-1749:
-----------------------------
Attachment: LUCENE-1749.patch
checkpoint: really hack implementation of checkFieldCacheSubReaderSanity that
tells you when a FieldCache contains entries on the same field in a both
wrapper/inner readers ... but it doesn't tell you which entries (and unlike
checkFieldCacheTypeSanity it's no obvious just looking at the toString())
This patch causes an error in TestStressSort and *LOTS* of errors in
TestCustomScoreQuery, TestFieldScoreQuery, and TestOrdValues.
I'd like to think these errors are just from tests doing abnormal things, and
in the case of TesStressSort that may be true (it looks like it has some hinky
reuse of readers in a MultiReader) but in the other test cases where it's a
little easier to see at a glance what's going on, there's really nothing odd
here -- simple use of a single IndexSearcher to execute a CustomScoreQuery,
ValueSourceQuery, etc... these are each causing multiple FieldCache instances
to pop up for a single field (one keyed on the DirectoryReader and another
keyed on a CompoundFileReader$CSIndexInput)
i'm try to work on refactoring the sanity checking methods so they are easier
to use (and write some tests for them to prove the work as expected on both
sane/insane) but it would be helpful if someone who understands more about how
FieldCaches should look (pushed into the subreaders) could tyr out this patch
and let me know if these failures look legit.
> FieldCache introspection API
> ----------------------------
>
> Key: LUCENE-1749
> URL: https://issues.apache.org/jira/browse/LUCENE-1749
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Reporter: Hoss Man
> Priority: Minor
> Fix For: 2.9
>
> Attachments: fieldcache-introspection.patch, LUCENE-1749.patch,
> LUCENE-1749.patch, LUCENE-1749.patch, LUCENE-1749.patch
>
>
> FieldCache should expose an Expert level API for runtime introspection of the
> FieldCache to provide info about what is in the FieldCache at any given
> moment. We should also provide utility methods for sanity checking that the
> FieldCache doesn't contain anything "odd"...
> * entries for the same reader/field with different types/parsers
> * entries for the same field/type/parser in a reader and it's subreader(s)
> * etc...
--
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
