[
https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510508#comment-13510508
]
Robert Muir commented on SOLR-4114:
-----------------------------------
I agree with Jack about the mocking, its really needed.
I feel like with solr cloud it could help a lot, e.g. simulate this guy going
down and that guy and not deal with timing issues and so on.
Just like lucene doesn't actually write continuously to your disk until its
really full to TestIndexWriterOnDiskFull, it mocks the disk full.
Sure these mock techniques aren't perfect, but they are much easier to debug.
for "real integration tests" maybe junit isnt even the best tool for the job
anyway, so i would prefer if these were separate from the unit tests.
These integration tests are especially frustrating for lucene developers, who
*seriously* dont want to break solr when they change things underneath it. but
the test suite doesn't really allow this you know, and when something does
break its hard to tell if its just an unrelated sporatic fail, because the test
suite is unreliable in general.
There is just no replacement for good unit tests.
> 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
