[
https://issues.apache.org/jira/browse/SOLR-3755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13623541#comment-13623541
]
Shalin Shekhar Mangar commented on SOLR-3755:
---------------------------------------------
bq. The sub shard cores are created while the sub shard is in construction
state therefore their cloud descriptor keeps "construction" as the shard state.
If the sub shard leader goes down after the shard state has been changed to
"active", it sets the shard state to "construction" once again while publishing
itself as "down".
I've fixed it in the git branch. Although I don't like the fix very much. In
the git branch, I'm using the shardState and shardRange fields in
CloudDescriptor for a one-time usage. They are set to null once the new sub
shard core is registered (and the new sub shard is created in zk).
Maybe shardState and shardRange should be a core property instead?
> shard splitting
> ---------------
>
> Key: SOLR-3755
> URL: https://issues.apache.org/jira/browse/SOLR-3755
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
> Reporter: Yonik Seeley
> Attachments: SOLR-3755-combined.patch,
> SOLR-3755-combinedWithReplication.patch, SOLR-3755-CoreAdmin.patch,
> SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch,
> SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch,
> SOLR-3755-testSplitter.patch, SOLR-3755-testSplitter.patch
>
>
> We can currently easily add replicas to handle increases in query volume, but
> we should also add a way to add additional shards dynamically by splitting
> existing shards.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
