You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Yonik Seeley (JIRA)" <ji...@apache.org> on 2011/01/06 21:30:45 UTC
[jira] Issue Comment Edited: (LUCENE-2474) Allow to plug in a Cache
Eviction Listener to IndexReader to eagerly clean custom caches that use
the IndexReader (getFieldCacheKey)
[ https://issues.apache.org/jira/browse/LUCENE-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978493#action_12978493 ]
Yonik Seeley edited comment on LUCENE-2474 at 1/6/11 3:29 PM:
--------------------------------------------------------------
> > 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.
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.
> > 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).
was (Author: yseeley@gmail.com):
> > 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org