[
https://issues.apache.org/jira/browse/SOLR-8906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222661#comment-15222661
]
Erick Erickson commented on SOLR-8906:
--------------------------------------
Thanks, I'll take a look. So far I've hacked an "interface" that is just a
subset of LinkedHashMap to see if it could be made pluggable. Creating an
abstraction that's more generalized is high on the priority list, and working
with better cache implementations may make sense.
The biggest gain would be from not unloading caches that were likely to be used
again. The simple LRU implementation suffers from implementation patterns that
periodically access each entry exactly once (say for health check or some
such). Having the frequency of access incorporated into the eviction policy
would be A Good Thing.
That said, I haven't looked at all at the implementation of TinyLFU, and
probably won't get to it for a week or two so don't think I'm totally dropping
the ball in the meanwhile. Thanks for bringing it to my attention!
> Make transient core cache pluggable.
> ------------------------------------
>
> Key: SOLR-8906
> URL: https://issues.apache.org/jira/browse/SOLR-8906
> Project: Solr
> Issue Type: Improvement
> Reporter: Erick Erickson
> Assignee: Erick Erickson
>
> The current Lazy Core stuff is pretty deeply intertwined in CoreContainer.
> Adding and removing active cores is based on a simple LRU mechanism, but
> keeping the right cores in the right internal structures involves a lot of
> attention to locking various objects to update internal structures. This
> makes it difficult/dangerous to use any other caching algorithms.
> Any single age-out algorithm will have non-optimal access patterns, so making
> this pluggable would allow better algorithms to be substituted in those cases.
> If we ever extend transient cores to SolrCloud, we need to have load/unload
> decisions that are cloud-aware rather then entirely local so in that sense
> this is would lay some groundwork if we ever want to go there.
> So I'm going to try to hack together a PoC. Any ideas on the most sensible
> pattern for this gratefully received.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
