[
https://issues.apache.org/jira/browse/SOLR-8906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15227136#comment-15227136
]
Erick Erickson commented on SOLR-8906:
--------------------------------------
So I did hack together a PoC and it doesn't disrupt CoreContainer too much. I'm
not really ready to put it up since it's too crude. The "interface" is just
selected interfaces from LinkedHashMap for instance, but it works enough to
decouple internal locking of objects in CoreContainer from the plugin code
which was my first concern.
Thinking about this some more, I started asking myself why should only
transient cores be manipulated by the plugin? CoreContainer shouldn't really
need to care whether the core is transient or not for its purposes. Gotta think
about that some more. Once the state of the core is removed from being so
intertwined with CoreContainer, it seems like it would be adaptable to using
ZK as "the one source of truth" pretty easily...
> 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]
