[
https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510526#comment-13510526
]
Robert Muir commented on SOLR-4114:
-----------------------------------
Per I don't want to drown out your issue either. But when I see arguments to
add an e.g. 60 second test like this, I felt the need to speak up. Solr has a
lot of these tests today (many fail on a daily basis), but I'm not sure how
much use they really are.
If tests are failing constantly and nobody is fixing them: then there is a
problem :)
Look: I'm totally fine with such tests being annotated \@Nightly and running on
jenkins at night (as long as they are reliable and debuggable). But slowness
itself presents another barrier for someone else trying to debug the test.
So I think its important to have quicker, simpler unit tests to encourage
refactoring and good APIs. Solr is really missing this.
And of course for the record I agree with you about the whole issue of
refactoring in general. I feel like refactoring in solr is not really
encouraged, because there is no faith in the test suite. So its safer to just
stick with the status quo instead. This is how projects die.
> 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: [email protected]
For additional commands, e-mail: [email protected]
