lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (SOLR-3088) create shard placeholders
Date Wed, 08 Feb 2012 17:38:59 GMT

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

Mark Miller edited comment on SOLR-3088 at 2/8/12 5:38 PM:
-----------------------------------------------------------

My thoughts are in line with what Yonik has said.

I only saw this issue as:

dummy entries get added to the collection state - eg if you start the first node with -DnumShards=3,
one real shard entry is added to the collection state and two dummy entries. As Yonik says,
now all searches will fail because the 2 dummy shards are not 'up' and the full collection
is not available.

Again, as Yonik notes, a nice side effect is that you don't always have to pass numShards
= except perhaps in the future when you want to reshard if that ends up making sense. Is it
a little bit like storing the number of shards as you where? Heh - I guess it is - though
with the side affect of nodes being able to see a full view of what shards should be in the
collection right away (that is, the info is in the clusterstate.json).

I've been leaning towards getting the req to pass numShards every time out anyway having dealt
with it for a while now. This seems like a slightly more useful way to do it compared to just
storing that value though. As long as the system property would always update it, I never
had much of a problem with storing the value actually. I had been imagining you would trigger
a re shard by passing a new number - but I'm not even sure if that is how that will work out.

Essentially though, everything would work as it does now - I'm not sure we need to do anything
more in this issue?


                
      was (Author: markrmiller@gmail.com):
    My thoughts are in line with what Yonik has said.

I only saw this issue as:

dummy entries get added to the collection state - eg if you start the first node with -DnumShards=3,
one real shard entry is added to the collection state and two dummy entries. As Yonik says,
now all searches will fail because the 2 dummy shards are not 'up' and the full collection
is not available.

Again, as Yonik notes, a nice side effect is that you don't always have to pass numShards
= except perhaps in the future when you want to reshard if that ends up making sense. Is it
a little bit like storing the number of shards as you where? Heh - I guess it is - though
with the side affect of nodes being able to see a full view of what shards should be in the
collection right away (that is, the info is in the clusterstate.json).

I've been leaning towards getting the req to pass numShards every time out anyway having dealt
with it for a while now. This seems like a slightly more useful way to do it compared to just
storing that value though. As long as the system property would always update it, I never
had much of a problem with storing the value actually. I had been imagining you would trigger
a re shard by passing a new number - but I'm not even sure if that is how that will work out.

Essentially though, everything would work as it does now - I'm not sure we need to do anything
in this issue?


                  
> create shard placeholders
> -------------------------
>
>                 Key: SOLR-3088
>                 URL: https://issues.apache.org/jira/browse/SOLR-3088
>             Project: Solr
>          Issue Type: New Feature
>          Components: SolrCloud
>            Reporter: Yonik Seeley
>             Fix For: 4.0
>
>
> When creating a new collection, a placeholder for each shard should be created.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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