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] [Comment Edited] (SOLR-4114) Collection API: Allow multiple shards from one collection on the same Solr server
Date Wed, 05 Dec 2012 14:10:58 GMT

    [ https://issues.apache.org/jira/browse/SOLR-4114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510487#comment-13510487
] 

Per Steffensen edited comment on SOLR-4114 at 12/5/12 2:10 PM:
---------------------------------------------------------------

bq. I don't even think we need to argue about it really.

Well if that is your opinion you will have a problem working on big projects. You should find
a private project to work on in your basement. I think it is worth arguing about. Maybe not
on this issue/ticket, but in general in the community on the dev mailing list. I am surrounded
by professional testers in my everyday work, and what I hear from them is more and more pulling
towards behavioural testing.

bq. Currently solr has a lot of integration tests, how is that working out?!

I dont know how it works out, but if you see a lot of problems, I wouldnt blame the integration-test
over unit-test strategy (is such a strategy exists). I have a gut fealing about then main
problem of Solr is that no one ever dare to do refactoring - the code is a mess. And that
you really do not "trust your test-suite".

If you want to to be able to "trust you test-suite" enough to dare doing big refactorings,
integration/behavioural tests are by far the best. Typically when you do major refactoring
you do not change the system-behaviour seen from the outside. You basically re-organize the
code internally in order to be able to keep adding features, fixing bugs etc. without getting
too confused. Therefore "integration/behavioural" tests do not have to be changed during a
big refactor, and the ensure that your refactoring did not ruin functionality "seen from the
outside" (is it IS basically all you care about). Unit-tests usually have to be changed during
a major refactoring, because a big refactor often includes getting rid of existing "units",
splitting up existing "units", adding new "units" etc.
                
      was (Author: steff1193):
    bq. I don't even think we need to argue about it really.

Well if that is your opinion you will have a problem working on big projects. You should find
a private project to work on in you basement. I think it is worth arguing about. Maybe not
on this issue/ticket, but in general in the community on the dev mailing list. I am surrounded
by professional testers in my everyday work, and what I hear from them is more and more pulling
towards behavioural testing.

bq. Currently solr has a lot of integration tests, how is that working out?!

I dont know how it works out, but if you see a lot of problems, I wouldnt blame the integration-test
over unit-test strategy (is such a strategy exists). I have a gut fealing about then main
problem of Solr is that no one ever dare to do refactoring - the code is a mess. And that
you really do not "trust your test-suite".

If you want to to be able to "trust you test-suite" enough to dare doing big refactorings,
integration/behavioural tests are by far the best. Typically when you do major refactoring
you do not change the system-behaviour seen from the outside. You basically re-organize the
code internally in order to be able to keep adding features, fixing bugs etc. without getting
too confused. Therefore "integration/behavioural" tests do not have to be changed during a
big refactor. Unit-tests usually do, because a big refactor often includes getting rid of
existing "units", splitting up existing "units", adding new "units" etc.
                  
> 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