lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-2765) Shard/Node states
Date Wed, 12 Oct 2011 22:11:11 GMT

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

Yonik Seeley commented on SOLR-2765:
------------------------------------

Just catching up on these discussions - lots of great stuff guys!

bq. Also, should we consider JSON or YAML over XML? Solr has historically used XML for config,
but I don't want that to unduly influence the right choice here. Solr also has JSON support
(which I would like as better default for talking to Solr myself).

I think so.  There tends to be a knee-jerk reaction against XML from many developers these
days, and it seems like anything new being developed tends to use JSON.  It's not about size
or parsing speed - it's about what people will like the best.  We need to pick our battles,
and this one isn't worth fighting IMO.

Another random thing to think about when designing this "schema" is the restart scenario.
If a node comes back up, how does it know what shards it was previously serving?  It either
needs to be kept locally, or needs to be kept in zookeeper.  It sounds like we're leaning
toward keeping that info locally and then the node will advertise that when it comes back
up (i.e. I have replica X in in the "recovering" state). Same for other per-node info like
custom roles they were labeled with ("indexer", "searcher", etc)?  It feels like we want some
persistent node info around in ZK - it would certainly make monitoring and some other things
easier - but then one must worry about garbage collection (nodes that you never see again).

Sounds like the overseer should be the one deciding if a node that comes back up should try
and recover it's former replica(s)
or if it's been long enough (and another replica was created) that it should be assigned to
a new task.

Fun stuff!  Unfortunately I need to go work on my Lucene Eurocon proposal now...

                
> Shard/Node states
> -----------------
>
>                 Key: SOLR-2765
>                 URL: https://issues.apache.org/jira/browse/SOLR-2765
>             Project: Solr
>          Issue Type: Sub-task
>          Components: SolrCloud, update
>            Reporter: Yonik Seeley
>             Fix For: 4.0
>
>         Attachments: cluster_state-file.patch, combined.patch, incremental_update.patch,
scheduled_executors.patch, shard-roles.patch, solrcloud.patch, solrcloud.patch, solrcloud.patch
>
>
> Need state for shards that indicate they are recovering, active/enabled, or disabled.

--
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