[
https://issues.apache.org/jira/browse/SOLR-5146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897965#comment-13897965
]
Erick Erickson commented on SOLR-5146:
--------------------------------------
The tantalizing bit is it could "just work". Anything that uses "getCore" (as I
remember)
will autoload the core and carry out the request. That includes updates as well
as
queries. The trap here would be the time involved. Say some replicas had to be
loaded,
would a request timeout? In any lightly-loaded system, the chance that some of
the
replicas are down increases of course..
I haven't really thought it out, but the process most true the the notion of a
single machine
with lots of cores seems to be a cluster-wide sense of what should be loaded.
In fact,
I might think of it as collection rather than shard being transient. I doubt
one could use
ZK for this as it would require that every request to every node get some info
from ZK.
Hmmm, and my ignorance of ZK is showing, but is it possible for ZK to raise
"load/unload
yourself" events to the cluster? Mostly spinning half-baked ideas here, you
know the
ZK code far, far better than I do...
What fun!
> 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, 5.0
> Reporter: Erick Erickson
> Assignee: Shalin Shekhar Mangar
> Fix For: 5.0
>
>
> 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.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
