Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Message-ID: <330663282.1237890710886.JavaMail.jira@brutus>
Date: Tue, 24 Mar 2009 03:31:50 -0700 (PDT)
From: "Kaktu Chakarabati (JIRA)" <jira@apache.org>
To: solr-dev@lucene.apache.org
Subject: [jira] Commented: (SOLR-1082) Refactor caching layer to be JCache
 compliant (jsr-107). In particular, consider using ehcache implementation
In-Reply-To: <1793844869.1237851590670.JavaMail.jira@brutus>
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:comment-tabpanel&focusedCommentId=12688634#action_12688634 ] 

Kaktu Chakarabati commented on SOLR-1082:
-----------------------------------------

So:

1. The suggestion for complying with jcache in itself is not in address of a pending critical problem as much as it is a suggestion for moving forward with the caching infrastructure to an implementation that will be more pluggable and transparent than the current one - in specific the possibility of allowing swapping in any 3rd-party implementation that can offer better performance/functionality than the basic caches available in solr currently. 
Moreover, the architecture of the caching layer as described (https://jsr-107-interest.dev.java.net/javadoc/javax/cache/package-summary.html) seems to be pretty well-rounded, including treatment of cache statistics, event listeners, and an application-wide access pattern to the caches (CacheManager). I think this is just a solid standard to go with for formalizing a caching layer that will work well and wont require too much tinkering with/refactoring in the long run.

2. Ehcache is just one such implementation that seems to be already available, well-maintained and offer good performance and functionality out of the box - supporting among other things distributed caching/replication which i think is big, numerous eviction policies out of the box (LRU, LFU, FIFO), JMX and a highly pluggable framework. Its also heavily tested and has been used in major production environments as well some high-profile projects (Spring, Hibernate, Maven among others). Delegating implementation to such a project would probably do solr good in terms of both codebase maintenance  as well as performance, and again, doing it right via the API standard wont tie us down to it either.
    
3. As I see it, the current caching is pretty basic, and does not scale well to the kind of production-usage scenarios i have in mind. in specific: Supporting only LRU eviction policy, lack of a thorough benchmarking/unit-testing framework such as the one EHcache has alongside publicly available benchmark data and metrics, lack of a well-defined access pattern across the application ( internal caches are defined very differently than user/generic caches in the SolrIndexSearcher, e.g generic caches are doubly referenced by both a Map and a List inside the searcher, much of this implementation logic should probably be abstracted away to a CacheManager kind of object).
Also, some of the more serious issues (OOM's) I see with the current behavior when committing index updates while serving requests and having two searcher instances running concurrently, requiring up to twice the space needed in terms of cached objects, might very well be addressed with an implementation such as ehcache that supports Cache/Element-based expiry policies, disk flushing, and cache event listeners. 


> 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.
-
You can reply to this email to add a comment to the issue online.