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