[
https://issues.apache.org/jira/browse/LUCENE-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978493#action_12978493
]
Yonik Seeley commented on LUCENE-2474:
--------------------------------------
> > We've talked before about putting caches directly on the readers - that
> > still seems like the most straightforward approach?
> not sure I understand that. Do you mean getting FieldCache into the readers?
> And then what about cached filters?
It would be a cache of anything... one element of that cache would be the
FieldCache, there could be one for filters, or one entry per-filter.
> > We really need one cache that doesn't care about deletions, and one cache
> > that does.
> Isn't that up to the cache to decide?
Not with this current patch, as there is no mechanism to get a callback when
you do care about deletes. If I want to cache something that depends on
deletions, I want to purge that cache when the actual reader is closed (as
opposed to the reader's core cache key that is shared amongst all readers that
just have different deletions). So if we go a "close event" route, we really
want two different events... one for the close of a reader (i.e. deleted
matter), and one for the close of the segment (deletes don't matter).
> 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
>
>
> 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
