Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Sat, 16 Mar 2013 19:10:12 +0000 (UTC)
From: "Erick Erickson (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12419258.1237851487480.452541.1363461012769@arcas>
In-Reply-To: <JIRA.12419258.1237851487480@arcas>
References: <JIRA.12419258.1237851487480@arcas>
Subject: [jira] [Resolved] (SOLR-1082) Refactor caching layer to be JCache
 compliant (jsr-107). In particular, consider using ehcache implementation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/SOLR-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erick Erickson resolved SOLR-1082.
----------------------------------

    Resolution: Won't Fix

SPRING_CLEANING_2013. We can reopen if necessary.
                
> Refactor caching layer to be JCache compliant (jsr-107). In particular, consider using ehcache implementation
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-1082
>                 URL: https://issues.apache.org/jira/browse/SOLR-1082
>             Project: Solr
>          Issue Type: New Feature
>          Components: search
>    Affects Versions: 1.5
>            Reporter: Kaktu Chakarabati
>
> overhaul the caching layer to be compliant
> with the upcoming Jcache api (jsr-107).
> In specific, I've been experimenting some with ehcache
> (http://ehcache.sourceforge.net/ , Apache OS license) and it seems to be a
> very comprehensive implementation, as well as fully compliant with the jcache API.
> I think the benefits are numerous: in respect to ehcache itself, it seems to
> be a very mature implementation, supporting most classical cache schemes as
> well as some interesting distributed cache options (and of course,
> performance-wise its very lucrative in terms of reported multi-cpu scaling
> performance and  some of the benchmark figures they show).
> Further, abstracting away the caches to use the jcache api would probably
> make it easier in the future to make the whole caching layer more easily
> swappable with some other implementations that will probably crop up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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