[
https://issues.apache.org/jira/browse/SOLR-5146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023591#comment-17023591
]
Erick Erickson commented on SOLR-5146:
--------------------------------------
[~dsmiley] AFAIC, if you're going to be diving into this feel totally free to
make any changes to the JIRA you want ;). I created it mostly to have a marker
so people would know that transient cores weren't supported in SolrCloud. In a
similar vein, you can change the "TestLazyCores.java" to "TestTransientCores" ;)
As far as the design for the pluggable interface I totally agree that it's
awkward. When I was originally working on it the sponsor of the effort had
forked Solr and heavily customized the prior implementation (CoreContainer
etc). They wanted a less-painful upgrade path next time. So I pulled the
intertwined bits out of CoreContainer and made them accessible.
Making it pluggable really amounted to identifying all the bits in places like
CoreContainer that were needed and getting them into the interface. I always
thought of it as an intermediate step and could help inform a thoughtful
redesign. There's a use-case for each of the touch points, what would be good
is to identify whether all of those use-cases are necessary and/or could be
combined into something simpler, perhaps modifying Solr's core operations along
the way.
At root, there's a two-way set of communications that need to happen between
CoreContainer and the transient core code. As cores move through various phases
(loading, pendingOps, queued up for the closer thread etc.) it may or may not
be available for the plugin to do what it wants, say move it to another
location. So there have to be ways for the transient code to know what state
the core is in as it moves through it's lifecycle.
Conversely, when Solr is trying to do whatever it needs to, say close the core,
it needs the transient plugin not to do something conflicting.
The plugin can do anything it wants to the core. Move it physically,
temporarily suspend it, even move it to another machine if the infrastructure
is such that the external app knows how to resolve where the core is.
Some of the complexity is due to trying to operate on cores in parallel, and
the core operations have accumulated cruft over time. Whether we could reduce
the complexity of core manipulation and thus reduce the complexity of the
transient interface, as well as the complexity of CoreContainer is a fair
question.
If you are puzzled by how trivial some of the touch points are in the default
implementation, we can talk about why they're there, some of them were required
for the alternate implementation. If I can remember why 2 years later...
Anyway, if you want to totally redesign it, please feel free ;)
> 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, 6.0
> Reporter: Erick Erickson
> Assignee: David Smiley
> Priority: Major
>
> 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
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
