[
https://issues.apache.org/jira/browse/SOLR-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13532432#comment-13532432
]
Per Steffensen edited comment on SOLR-4120 at 12/14/12 4:30 PM:
----------------------------------------------------------------
h4. SOLR-4120_trunk_r1421793.patch
Hurry up, get it in, Mark - while its still hot!
Did not run entire test-suite after this patch, but I did run
OverseerCollectionProcessorTest and BasicDistributedZkTest to verify that they
are both green. Hope I did not ruin other tests - couldnt imagine.
h5. Where does it fit
* It fits trunk (5.x) revision 1421793
h5. Content of patch
* Same as for the lucene_solr_4_0 patch
h5. Testing
* Same as for the lucene_solr_4_0 patch
* Added tests for the feature in OverseerCollectionProcessorTest. Tests
checking detailed combinations that does not belong in the "slow" tests in
BasicDistributedZkTest. Also testing the SOLR-4114 and SOLR-4120 features in
combination - that is, situations where createNodeSet is so small that the
collection cannot be created living up to numShards and replicationFactor
without violating the maxShardsPerNode (SOLR-4114) limit, but where it would
have been possible to create the collection if either of maxShardsPerNode was
higher or if createNodeSet had not been specified.
was (Author: steff1193):
h4. SOLR-4120_trunk_r1421793.patch
Hurry up, get it in, Mark - while its still hot!
Did not run entire test-suite after this patch, but I did run
OverseerCollectionProcessorTest and BasicDistributedZkTest to verify that they
are both green. Hope I did not ruin other tests - couldnt imagine.
h5. Where does it fit
* It fits trunk (5.x) revision 1421793
h5. Content of patch
* Same as for the lucene_solr_4_0 patch
h5. Testing
* Same as for the lucene_solr_4_0 patch
* Added tests for the feature in OverseerCollectionProcessorTest. Tests
checking detailed combinations that does not belong in the "slow" tests in
BasicDistributedZkTest. Also testing the SOLR-4114 and SOLR-4120 features in
combination - that is, situations where createNodeSet is so small that the
collection cannot be cannot be created living up to numShards and
replicationFactor without violating the maxShardsPerNode (SOLR-4114) limit, but
where it would have been possible to create the collection if either of
maxShardsPerNode or createNodeSet had not been specified in the request.
> Collection API: Support for specifying a list of solrs to spread a new
> collection across
> ----------------------------------------------------------------------------------------
>
> Key: SOLR-4120
> URL: https://issues.apache.org/jira/browse/SOLR-4120
> Project: Solr
> Issue Type: New Feature
> Components: multicore, SolrCloud
> Affects Versions: 4.0
> Reporter: Per Steffensen
> Assignee: Mark Miller
> Priority: Minor
> Labels: collection-api, multicore, shard, shard-allocation
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4120.patch, SOLR-4120_trunk.patch,
> SOLR-4120_trunk_r1421793.patch
>
>
> When creating a new collection through the Collection API, the Overseer
> (handling the creation) will spread shards for this new collection across all
> live nodes.
> Sometimes you dont want a collection spread across all available nodes. Allow
> for the create operation of the Collection API, to take a createNodeSet
> parameter containing a list of Solr to spread the new shards across. If not
> provided it will just spread across all available nodes (default).
> For an example of a concrete case of usage see:
> https://issues.apache.org/jira/browse/SOLR-4114?focusedCommentId=13505506&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13505506
--
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: [email protected]
For additional commands, e-mail: [email protected]
