[ 
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086291#comment-13086291
 ] 

Michael McCandless commented on LUCENE-3360:
--------------------------------------------

bq. The current FielCache api requires a reader to be specified. That specified 
reader is used as key.

Ahh I see -- the SlowMRWrapper's FC impl uses the "in" (wrapped IndexReader, 
from FilterIndexReader) as the key.  So we should only see one cache entry 
created.  Phew!

bq. When back porting to 3x we obviously need to keep FieldCache classes...

True... so maybe do this patch in 2 steps?  First, for 3.x.  Then, merge to 
trunk, remove deprecated FC and fix all usages?

> Move FieldCache to IndexReader
> ------------------------------
>
>                 Key: LUCENE-3360
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3360
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Martijn van Groningen
>             Fix For: 3.4, 4.0
>
>         Attachments: LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch
>
>
> Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so 
> that FieldCache insanity caused by the WeakHashMap no longer occurs.
> * Add a new method to IndexReader that by default throws an UOE:
> {code}public FieldCache getFieldCache(){code}
> * The SegmentReader implements this method and returns its own internal 
> FieldCache implementation. This implementation just uses a 
> HashMap<Entry<T>,Object>> to store entries.
> * The SlowMultiReaderWrapper implements this method as well and basically 
> behaves the same as the current FieldCacheImpl.
> This issue won't solve the insanity that comes from inconsistent usage of a 
> single field (for example retrieve both int[] and DocTermIndex for the same 
> field). 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to