[
https://issues.apache.org/jira/browse/LUCENE-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787585#action_12787585
]
Earwin Burrfoot commented on LUCENE-2135:
-----------------------------------------
bq. Please see LUCENE-2133 for a refactoring of FieldCache, which also
addresses these problems.
It doesn't address a problem of adding custom components to IR. It also does
complicate IR beyond that unholy mess it already is.
I think it's better to have an ability to add 'any' kind of component to IR,
and then implement whateverCaches over it.
> IndexReader.close should forcefully evict entries from FieldCache
> -----------------------------------------------------------------
>
> Key: LUCENE-2135
> URL: https://issues.apache.org/jira/browse/LUCENE-2135
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 3.1
>
>
> Spinoff of java-user thread "heap memory issues when sorting by a string
> field".
> We rely on WeakHashMap to hold our FieldCache, keyed by reader. But this
> lacks immediacy on releasing the reference, after a reader is closed.
> WeakHashMap can't free the key until the reader is no longer referenced by
> the app. And, apparently, WeakHashMap has a further impl detail that requires
> invoking one of its methods for it to notice that a key has just become only
> weakly reachable.
> To fix this, I think on IR.close we should evict entries from the FieldCache,
> as long as the sub-readers are truly closed (refCount dropped to 0).
--
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: [email protected]
For additional commands, e-mail: [email protected]
