[ 
https://issues.apache.org/jira/browse/SOLR-5146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628765#comment-14628765
 ] 

Scott Blum commented on SOLR-5146:
----------------------------------

I would just like to add a thought here, maybe we could redefine what it means 
for a core to be loaded/unloaded/transient.  Hear me out for a second... the 
real operational problem with having tons of cores all loaded at once is the 
enormous amount of heap required, since all cores maintain their own caches.  
If we could simply have "inactive" cores dump all their caches (maybe the whole 
searcher?) but continue to participate in solrcloud/zk, wouldn't that make the 
problem a lot simpler?

> Figure out what it would take for lazily-loaded cores to play nice with 
> SolrCloud
> ---------------------------------------------------------------------------------
>
>                 Key: SOLR-5146
>                 URL: https://issues.apache.org/jira/browse/SOLR-5146
>             Project: Solr
>          Issue Type: Improvement
>          Components: SolrCloud
>    Affects Versions: 4.5, Trunk
>            Reporter: Erick Erickson
>            Assignee: Shalin Shekhar Mangar
>             Fix For: Trunk
>
>
> The whole lazy-load core thing was implemented with non-SolrCloud use-cases 
> in mind. There are several user-list threads that ask about using lazy cores 
> with SolrCloud, especially in multi-tenant use-cases.
> This is a marker JIRA to investigate what it would take to make lazy-load 
> cores play nice with SolrCloud. It's especially interesting how this all 
> works with shards, replicas, leader election, recovery, etc.
> NOTE: This is pretty much totally unexplored territory. It may be that a few 
> trivial modifications are all that's needed. OTOH, It may be that we'd have 
> to rip apart SolrCloud to handle this case. Until someone dives into the 
> code, we don't know.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to