lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Steffensen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-4114) Collection API: Allow multiple shards from one collection on the same Solr server
Date Wed, 05 Dec 2012 15:10:58 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message