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 Tue, 04 Dec 2012 19:50:59 GMT

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

Per Steffensen commented on SOLR-4114:
--------------------------------------

bq. We poll so that we wait up to 120 seconds for a slow comp, but a fast comp won't need
to wait nearly that long. The 60 wait hits everyone no matter what. We generally try avoid
any hard waits like that. I understand you can't really poll in this case, so I'm not sure
the best way to test that - I made it a TODO for now.

Ok with a TODO, but it should be about making a more clever solution than the 60 sec wait.
You commented out the assert-method "checkCollectionIsNotCreated", which means that we now
have an unprotected feature in the code-base. Anyone can go ruin this feature tomorrow and
no one will notice. Yes, I believe the main value of tests is their ability to "protect" other
people from accidently ruining existing fuctionality. All the comments below are very unimportant
compared to this - I am really serious about this. Get "checkCollectionIsNotCreated" running
now so that the code is protected, then think about a more clever solution later (if you think
such a thing exists). TODO's have a tendency to be forgotten.

bq. Yeah, I minimized the patch down to just dealing with this issue. I'm away from home and
just looking to get this issue completed with minimum fuss.

Then the easiest thing would probably have been, to take everything in, except for things
you thought would actually ruin existing stuff. Instead of using time to find every little
detail that could be left out. Do not misunderstand me, I am glad you used your time to get
it committed, but I also want to influence the way you committers work, whenever I have the
chance. Only thinking about our common interrest - a good Solr. I have a bad gut feeling that
the code-base is so messy because no one ever refactors. Refactoring is something you usually
do while solving some specific (potentially) unrelated task. No one goes refactoring just
to do refactoring, but it is extremely important that refactoring has an easy way into the
code-base.

bq. 'nodeUrlWithoutProtocolPart' is just so long and I didn't see it helping much in terms
of code readability - if you have a better fitting name that is a little less verbose, I think
I'd be more into it.

Well, first of all a long saying name is much better than a short misleading name, and second
of all that name really isnt very long :-)

bq. Yeah, I don't think I agree with changing the users params on him - I'd rather warn and
let the user do what he wants to do rather than trying to outthink him ahead of time. If he
decides he wants more than one repica on an instance for some reason, that's his deal - we
can warn him though.

Ok, cool

bq. Right - it should match collection1 - eg newcollection/data should be the data dir just
like collection1/data and rather than something like newcollection_data. In my experience
and testing, data ends up in the cores own instance dir - not some common dir.

Didnt learn much from this explanation, but I will have to do a little studying on instance-dir
and data-dir to understand how your solution will ever work. I will get back with an official
complaint (just a comment here or a mail on the mailing list :-) ) if I still do not think
it will work after I have done my studying.

bq. Yup - it seemed unrelated and I'm busy so I didn't want to think about it...

Still easier to just take it in, unless you saw it harming more than it helped. I am worried
about refactoring in this project! Trust your test-suite :-)

                
> 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