[
https://issues.apache.org/jira/browse/SOLR-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688788#action_12688788
]
Hoss Man commented on SOLR-1082:
--------------------------------
Ultimately this issue seems to be about supporting more choices for the users
by implementing/utilizing a "standard" Caching API. Specific arguments
for/against the current implementations of the SolrCache interface, or
comparisons of those implementations to something like ecache aren't really
relevant at this time.
what is relevant is:
1) Would more options/features be available to users if the existing hooks for
using SolrCache API were refactored to support the JCache API?
2) what would be involved in making changes to do this?
3) would these changes be backwards compatible for existing users -- both in
terms of
features and existing performance characteristics.
These seem like questions whose answers won't really be understood until there
are some rough patches to discuss.
> 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.
