[
https://issues.apache.org/jira/browse/LUCENE-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978719#action_12978719
]
Shay Banon commented on LUCENE-2474:
------------------------------------
> 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.
> edit: Maybe a better way to think about it is like a ServletContext or
> something - it's just a way to attach anything arbitrary to a reader.
Got you. My personal taste is to try and keep those readers as lightweight as
possible, and have the proper constructs in place to allow to externally use
them for caching, without having them manage it as well.
> 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).
I think that a cache that is affected by deletes is a problematic cache to
begin with, so was thinking that maybe it should be discouraged by not allowing
for it. Especially with NRT. My idea was to simply expand the purge capability
that the FC gets for free to other external custom components.
Also, if we did have a type safe separation between segment readers and
compound readers, I would not have added the ability to register a listener on
the compound readers, just the segment readers, as this will encourage people
to write caches that only work on segment readers (since the registration for
the "purge event" will happen within the cache, and it should work only with
segment readers). That was why my patch does not take compound readers into
account.
> 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: [email protected]
For additional commands, e-mail: [email protected]
