[
https://issues.apache.org/jira/browse/LUCENE-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983818#action_12983818
]
Yonik Seeley commented on LUCENE-2474:
--------------------------------------
bq. eg if you make a MultiReader (or ParallelReader) w/ subs... what should
happen to their listeners?
This doesn't have to be a super-flexible public API - it's clearly expert level
and we can impose limitations that make sense.
A MultiReader is just a wrapper - you don't reopen it, so it could just start
off with an empty listener list, the subs could all retain their listener lists
and an addListener() could just delegate to the contained readers.
bq. ReaderContext doesn't really make sense here?
Right, it doesn't (which circles around to the fact that the callbacks should
be set on the top-reader)
bq. Isn't this "typically" a containsKey against the app level caches...?
In a (solr) multi-core environment, you don't know *which* caches to check, or
even how to get to those caches.
You would either need to add *all* of them and check all of them on a purge
(which has other problems, including performance
problems for highly multi-tenanted uses where people have thousands of cores),
or have one big static cache (which has other problems such as not being
configurable per-core).
I'm not against this patch, I'm just pointing out that the "staticness" of it
(which I hope we can continue to move away from over time) severely limits it's
usefulness, and it doesn't represent incremental progress if we do want to get
rid of statics.
Actually, I am against the last patch you posted, as it clearly has nothing to
do with this issue ;-)
> 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, LUCENE-2574.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
