[
https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509861#comment-13509861
]
Mark Miller commented on SOLR-4114:
-----------------------------------
Yeah, I minimized the patch down to just dealing with this issue. I'm away from
home and just looking to get this issue completed with minimum fuss.
'nodeUrlWithoutProtocolPart' is just so long and I didn't see it helping much
in terms of code readability - if you have a better fitting name that is a
little less verbose, I think I'd be more into it.
bq. I see that you removed the "auto-reduce replica-per-shard t
Yeah, I don't think I agree with changing the users params on him - I'd rather
warn and let the user do what he wants to do rather than trying to outthink him
ahead of time. If he decides he wants more than one repica on an instance for
some reason, that's his deal - we can warn him though.
bq. You removed the following lines (because you just want default-values for
instance-dir and data-dir)
Right - it should match collection1 - eg newcollection/data should be the data
dir just like collection1/data and rather than something like
newcollection_data. In my experience and testing, data ends up in the cores own
instance dir - not some common dir.
bq. making "shardToUrls"-map (renamed) concurrency protected
Yup - it seemed unrelated and I'm busy so I didn't want to think about it. My
goal is to get the essence of this thing committed - it's a lot easier to then
fight over smaller pieces on top of that. Progress not perfection.
> Collection API: Allow multiple shards from one collection on the same Solr
> server
> ---------------------------------------------------------------------------------
>
> Key: SOLR-4114
> URL: https://issues.apache.org/jira/browse/SOLR-4114
> Project: Solr
> Issue Type: New Feature
> Components: multicore, SolrCloud
> Affects Versions: 4.0
> Environment: Solr 4.0.0 release
> Reporter: Per Steffensen
> Assignee: Per Steffensen
> Labels: collection-api, multicore, shard, shard-allocation
> Attachments: SOLR-4114.patch, SOLR-4114.patch, SOLR-4114.patch,
> SOLR-4114.patch, SOLR-4114_trunk.patch
>
>
> We should support running multiple shards from one collection on the same
> Solr server - the run a collection with 8 shards on a 4 Solr server cluster
> (each Solr server running 2 shards).
> Performance tests at our side has shown that this is a good idea, and it is
> also a good idea for easy elasticity later on - it is much easier to move an
> entire existing shards from one Solr server to another one that just joined
> the cluter than it is to split an exsiting shard among the Solr that used to
> run it and the new Solr.
> See dev mailing list discussion "Multiple shards for one collection on the
> same Solr server"
--
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
