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