lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kaktu Chakarabati (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-1082) Refactor caching layer to be JCache compliant (jsr-107). In particular, consider using ehcache implementation
Date Tue, 24 Mar 2009 10:31:50 GMT

    [ 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.


Mime
View raw message