[
https://issues.apache.org/jira/browse/SOLR-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13892975#comment-13892975
]
Mark Miller commented on SOLR-5476:
-----------------------------------
The problem is the reliance on the isLeader checks in the over seer threads to
kill the previous overseer. It's a race, and the tests are showing how easy it
is for multiple overseers to interfere with each other. We have to avoid those
races, both because the current impls require it, but also because who knows
what future things the overseer may do. The Overseer must be a mutually
exclusive process 100%.
I'm not sure that we can bullet proof this approach. Perhaps. But I wouldn't
believe it until we had some much stronger testing. The current test fails
almost every run for me when I run it in eclipse because Overseers interfere
with each other.
I'm also a little scared of the way this messes with the election process, but
that appears like it should be okay.
> 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: 5.0, 4.7
>
> Attachments: 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: [email protected]
For additional commands, e-mail: [email protected]
