lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-5823) Add utility function for internal code to know if it is currently the overseer
Date Fri, 07 Mar 2014 18:13:50 GMT

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

Hoss Man commented on SOLR-5823:
--------------------------------

miller & i talked a bit about this on IRC this morning, a few summary points...

* the reasons i'm looking for a general "am i the leader" type method, that can be run as
part of a scheduled executor -- instead of adding a new processing thread to the Overseer
class is two fold:
** i want the logic to be usable even if we aren't in cloud mode
** i'm trying to think about how other people who write plugins/components would be able to
do the same thing w/o needing to modify the overseer.

* Tim's patch goes the route of ensuring every node can ask "what is the name of the overseer
node" and then implements "am i the overseer node" by comparing our name with the overser
name
** in the case of "who is the shard leader" and "am i the shard leader" that info is cached
in the cluster state info, so calling those methods doesn't hit ZK everytime
** we don't want to cache the overseer info in a similar way, because it's risky and 99% of
the time, nodes don't care "who is the overseer"

Which brought me to the key question where miller & i realized we had gotten side tracked...

* i don't really care about the "what is the name of the overseer node" case -- and most people
shouldn't -- i'm really just looking for the "am i currently the overseer?" part of the equation
** this as a simple boolean should be a much easier question to answer efficiently, because
of how the overseer election works -- if a node is the overseer, it's running hte overseer
processing threads
** part of my confusion was the terminology: the idea of "Leader" is used a lot in the overseer
code, but that's not refering to "shard leader" in the solr context, it's refering to the
ZK jargon of "leader election", in many cases (in the overseer classes) it refers to "who
is the ("zk leader" in charge of being the) overseer"

At this point, miller got disconnected from IRC ... but digging in a bit and thinking about
what he was telling me, it seems like we should be able to add an efficient "ZkController.isOverseer()"
method (that doesn't have to hit Zk directly), by checking if the Overseer object is active
or closed -- either with a new state boolean, or maybe just by checking the threads it manages
for "null"


> Add utility function for internal code to know if it is currently the overseer
> ------------------------------------------------------------------------------
>
>                 Key: SOLR-5823
>                 URL: https://issues.apache.org/jira/browse/SOLR-5823
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Hoss Man
>         Attachments: SOLR-5823.patch
>
>
> It would be useful if there was some Overseer equivalent to CloudDescriptor.isLeader()
that plugins running in solr could use to know "At this moment, am i the leader?" 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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


Mime
View raw message