[
https://issues.apache.org/jira/browse/LUCENE-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983159#action_12983159
]
Michael McCandless commented on LUCENE-2474:
--------------------------------------------
bq. Still, I think that using CopyOnWriteArrayList is best here.
OK I'll switch back to COWAL... it makes me nervous though. I like
being defensive and the added cost of CHM iteration really should be
negligible here.
{quote}
I'd like even more for there to be just a single CopyOnWriteArrayList per
"top-level" reader that is then propagated to all sub/segment readers,
including new ones on a reopen. But I guess Mike indicated that was currently
too hard/hairy.
{quote}
This did get hairy... eg if you make a MultiReader (or ParallelReader)
w/ subs... what should happen to their listeners? Ie what if the subs
already have listeners enrolled?
It also spooked me that apps may think they have to re-register after
re-open (if we stick w/ ArrayList) since then the list'd just grow...
it's trappy.
And, if you pull an NRT reader from IW (which is what reopen does
under the hood for an NRT reader), how to share its listeners? Ie,
we'd have to add a setter to IW as well, so it's also "single source"
(propagates on reopen).
This is why I fell back to a simple static as the baby step for now.
{quote}
The static is really non-optimal though - among other problems, it requires
systems with multiple readers (and wants to do different things with different
readers, such as maintain separate caches) to figure out what top-level reader
a segment reader is associated with. And given that we are dealing with
IndexReader instances in the callbacks, and not ReaderContext objects, this
seems impossible?
{quote}
ReaderContext doesn't really make sense here?
Ie, the listener is invoked when any/all composite readers sharing a
given segment have now closed (ie when the RC for that segment's core
drops to 0), or when a composite reader is closed.
Also, in practice, is it really so hard for the app to figure out
which SR goes to which of their caches? Isn't this "typically" a
containsKey against the app level caches...?
> Allow to plug in a Cache Eviction Listener to IndexReader to eagerly clean
> custom caches that use the IndexReader (getFieldCacheKey)
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-2474
> URL: https://issues.apache.org/jira/browse/LUCENE-2474
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Reporter: Shay Banon
> Attachments: LUCENE-2474.patch, LUCENE-2474.patch
>
>
> Allow to plug in a Cache Eviction Listener to IndexReader to eagerly clean
> custom caches that use the IndexReader (getFieldCacheKey).
> A spin of: https://issues.apache.org/jira/browse/LUCENE-2468. Basically, its
> make a lot of sense to cache things based on IndexReader#getFieldCacheKey,
> even Lucene itself uses it, for example, with the CachingWrapperFilter.
> FieldCache enjoys being called explicitly to purge its cache when possible
> (which is tricky to know from the "outside", especially when using NRT -
> reader attack of the clones).
> The provided patch allows to plug a CacheEvictionListener which will be
> called when the cache should be purged for an IndexReader.
--
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
