Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <921412066.1239555735595.JavaMail.jira@brutus>
Date: Sun, 12 Apr 2009 10:02:15 -0700 (PDT)
From: "Mark Miller (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Issue Comment Edited: (LUCENE-831) Complete overhaul of
 FieldCache API/Implementation
In-Reply-To: <19567919.1173857169285.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Mark Miller edited comment on LUCENE-831 at 4/12/09 10:00 AM:
--------------------------------------------------------------

bq. Ugly.

Well no worries yet :) Still in early design mode, so if it can be made better, I'm sure it will. Of course I'd love to get to 'everything works right for the right field automagically' as well - not sure that will fit into the scope of this issue though (though nothing saying this issue can't be further delayed). We will do the best we can regardless though.

I'm kind of worried that any change is going to hurt Apps like Solr - if you end up using the new built in API, but also have code that must stick for a while with the old API (for multireader fieldcache or something), you'll likely increase RAM usage more than before - how much of a concern that ends up being, I'm not sure. I suppose eventually it has to become up to the upgrader to consider and deal with it if we want to move to segment level caching.

*edit*

Little behind on that worry I guess - we already pumped that problem out the door with 1483. Half in the clouds over here.

      was (Author: markrmiller@gmail.com):
    bq. Ugly.

Well no worries yet :) Still in early design mode, so if it can be made better, I'm sure it will. Of course I'd love to get to 'everything works right for the right field automagically' as well - not sure that will fit into the scope of this issue though (though nothing saying this issue can't be further delayed). We will do the best we can regardless though.

I'm kind of worried that any change is going to hurt Apps like Solr - if you end up using the new built in API, but also have code that must stick for a while with the old API (for multireader fieldcache or something), you'll likely increase RAM usage more than before - how much of a concern that ends up being, I'm not sure. I suppose eventually it has to become up to the upgrader to consider and deal with it if we want to move to segment level caching.
  
> Complete overhaul of FieldCache API/Implementation
> --------------------------------------------------
>
>                 Key: LUCENE-831
>                 URL: https://issues.apache.org/jira/browse/LUCENE-831
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Hoss Man
>            Assignee: Mark Miller
>             Fix For: 3.0
>
>         Attachments: ExtendedDocument.java, fieldcache-overhaul.032208.diff, fieldcache-overhaul.diff, fieldcache-overhaul.diff, LUCENE-831.03.28.2008.diff, LUCENE-831.03.30.2008.diff, LUCENE-831.03.31.2008.diff, LUCENE-831.patch, LUCENE-831.patch, LUCENE-831.patch, LUCENE-831.patch, LUCENE-831.patch, LUCENE-831.patch, LUCENE-831.patch, LUCENE-831.patch
>
>
> Motivation:
> 1) Complete overhaul the API/implementation of "FieldCache" type things...
>     a) eliminate global static map keyed on IndexReader (thus
>         eliminating synch block between completley independent IndexReaders)
>     b) allow more customization of cache management (ie: use 
>         expiration/replacement strategies, disk backed caches, etc)
>     c) allow people to define custom cache data logic (ie: custom
>         parsers, complex datatypes, etc... anything tied to a reader)
>     d) allow people to inspect what's in a cache (list of CacheKeys) for
>         an IndexReader so a new IndexReader can be likewise warmed. 
>     e) Lend support for smarter cache management if/when
>         IndexReader.reopen is added (merging of cached data from subReaders).
> 2) Provide backwards compatibility to support existing FieldCache API with
>     the new implementation, so there is no redundent caching as client code
>     migrades to new API.

-- 
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org