[
https://issues.apache.org/jira/browse/SOLR-9273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15359209#comment-15359209
]
Erick Erickson commented on SOLR-9273:
--------------------------------------
I started looking at this along side shareSchema and quickly gave up due to
what you've outlined. Actually I didn't get that far, just poked around long
enough to say "Oh my, this is complicated"...
So would this mean that there's one way of loading solrconfig in stand-alone
and one for SolrCloud? And, if so, would it make sense to deal with Zookeeper
as "the one source of truth" first? Or would we impose the same restrictions on
stand-alone Solr re: point <1>? I'm not against any of those options, just
wondering what the thinking is here...
But this would be great for those situations where people have lots of replicas
sharing a configset. I did some timings a while ago for core discovery and it
was something like 1,000/second for just the discovery part. Might it be
possible to hit 100 cores/second with this?
Just had a random thought here. Currently core loading implicitly throttles ZK
state changes, so I do wonder at the effects on Zookeeper/event notification to
the clients... I can't point to anything bad here, more of "gee, I wonder how
that'll work"....
> Share and reuse config set in a node
> ------------------------------------
>
> Key: SOLR-9273
> URL: https://issues.apache.org/jira/browse/SOLR-9273
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: config-api, Schema and Analysis, SolrCloud
> Reporter: Shalin Shekhar Mangar
> Fix For: 6.2, master (7.0)
>
>
> Currently, each core in a node ends up creating a completely new instance of
> ConfigSet with its own schema, solrconfig and other properties. This is
> wasteful when you have a lot of replicas in the same node with many of them
> referring to the same config set in Zookeeper.
> There are many issues that need to be addressed for this to work so this is a
> parent issue to track the work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
