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

Mark Miller commented on SOLR-5476:
-----------------------------------

The testing for this is still super minimal. Also the following was not 
addressed:

{noformat}
I also think we need to add some defensive programming. If we try and remove a 
queue item that is not there, we should assume another overseer already ate it 
rather than letting the Overseer thread die.
{noformat}

I don't think much of what I was concerned about was addressed. The test can 
also still fail because two Overseers are running at the same time (Mike just 
saw this).

If this didn't go out in 4.7 I would bring back the -1.

This is why I said on the phone that I would prefer we mark it as experimental 
- so that it could still be vetoed after release if the problems were not 
addressed.

> Overseer Role for nodes
> -----------------------
>
>                 Key: SOLR-5476
>                 URL: https://issues.apache.org/jira/browse/SOLR-5476
>             Project: Solr
>          Issue Type: Sub-task
>          Components: SolrCloud
>            Reporter: Noble Paul
>            Assignee: Noble Paul
>             Fix For: 4.7, 5.0
>
>         Attachments: SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch, 
> SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch, SOLR-5476.patch
>
>
> In a very large cluster the Overseer is likely to be overloaded.If the same 
> node is a serving a few other shards it can lead to OverSeer getting slowed 
> down due to GC pauses , or simply too much of work  . If the cluster is 
> really large , it is possible to dedicate high end h/w for OverSeers
> It works as a new collection admin command
> command=addrole&role=overseer&node=192.168.1.5:8983_solr
> This results in the creation of a entry in the /roles.json in ZK which would 
> look like the following
> {code:javascript}
> {
> "overseer" : ["192.168.1.5:8983_solr"]
> }
> {code}
> If a node is designated for overseer it gets preference over others when 
> overseer election takes place. If no designated servers are available another 
> random node would become the Overseer.
> Later on, if one of the designated nodes are brought up ,it would take over 
> the Overseer role from the current Overseer to become the Overseer of the 
> system



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to