[
https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510522#comment-13510522
]
Per Steffensen commented on SOLR-4114:
--------------------------------------
bq. but it should be used as an adjunct, not a replacement for hard-core unit
testing
Guess I kinda agree, just dont overdue the hard-core unit testing, and
certainly not forget to do the behavioural/integration tests.
bq. Solr is screaming out for a "mocking" capability so that more "integration"
testing can be done at the unit test level
Uhhh yes. Mocking is a nice way of having your "integration" tests not include
the whole world. E.g. an a test included the entire request handling, seen from
the outside down to the OverseerCollectionProcessor, but where we mock the
calls to the Core Admin API and just assert that the requests forwarded to the
Core Admin API is as expected. Mocking capability in Solr will take tests to
the next level, but why not just start using it? - e.g. mockito is just go-use.
bq. its hard to tell if its just an unrelated sporatic fail, because the test
suite is unreliable in general
Yes, my impression is also that the tests are unreliable - sometimes fail and
sometimes not, and it is really hard to know if you did something wrong. But I
will still claim that it is not because of integration tests - it might be
because they, as so many other things in Solr, are done in a undisciplined way.
Well everyone have their experience and believes and I am always glad to
discuss with you guys. Glad that you decided to really join Robert, even though
you thought that there where nothing to discuss. But I guess I have stated my
opinion now, and I dont want to do any more debating here on this issue/ticket.
If you want to continue on the mailing-list I will probably join, but this
issue/ticket should be about this issue/ticket from now on. We still have
unhandled matters (e.g. controlling instance-dir and/or data-dir), and I dont
want the discussion about those matters to drown in "partly" unrelated
discussions about test-strategies.
> 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
