cryptoe opened a new pull request, #13251:
URL: https://github.com/apache/druid/pull/13251

   <!-- Thanks for trying to help us make Apache Druid be the best it can be! 
Please fill out as much of the following information as is possible (where 
relevant, and remove it when irrelevant) to help make the intention and scope 
of this PR clear in order to ease review. -->
   
   <!-- Please read the doc for contribution 
(https://github.com/apache/druid/blob/master/CONTRIBUTING.md) before making 
this PR. Also, once you open a PR, please _avoid using force pushes and 
rebasing_ since these make it difficult for reviewers to see what you've 
changed in response to their reviews. See [the 'If your pull request shows 
conflicts with master' 
section](https://github.com/apache/druid/blob/master/CONTRIBUTING.md#if-your-pull-request-shows-conflicts-with-master)
 for more details. -->
   
   Currently, in the Druid Leader selector, we have 2 states only. Either the 
process is a leader or not. 
   But we need a 3rd state which represents an initialized leader on which 
external callers should gate on.
   
   According to the zookeeper, once we receive the callback inside 
`LeaderLatchListener#isLeader()` that candidate is the leader. In Druid, we can 
take some time in running the `DruidLeaderSelector#listener` since there are a 
lot of DB operations done in both the overlord and the coordinator which can 
take time. Also for all "endpoints", a leader is usable only when it's 
initialized. 
   
    
    Another race condition was how `CuratorDruidLeaderSelector` was updating 
the boolean variable `leader`. 
    As `DruidLeaderSelector#listener#becomeLeader()` can take some time to run, 
zk can choose to change leadership behind the scenes. So now we can have two 
processes thinking they are the leaders. Changed 
`CuratorDruidLeaderSelector#isLeader()` to gate on the "latchStatus" rather 
than the local boolean `leader` variable. 
    
   As the `leader` variable is updated in a single-threaded executor service 
the following situation can very well happen. 
   Lets say we have two overlords foo, bar. 
   
   ```
    t0: foo is chosen the leader by ZK,  print 
"Grayskull"----------------------------------------t10: initialized 
    ----t1: notLeader listener is called but is waiting cause exec is single 
threaded -------------------t11: bar isNotLeader()-> leader =false
    -------t2: bar is leader, print "Grayskull"-----------t5: initialized 
   ```
   Between t5-t11, both foo,bar think they are the leaders. 
   
   ##### Key changed/added classes in this PR
    * `DruidLeaderSelector`
    * `CuratorLeaderSelector`
    * `DruidCoordinator`
   
   <hr>
   
   <!-- Check the items by putting "x" in the brackets for the done things. Not 
all of these items apply to every PR. Remove the items which are not done or 
not relevant to the PR. None of the items from the checklist below are strictly 
necessary, but it would be very helpful if you at least self-review the PR. -->
   
   This PR has:
   
   - [ ] been self-reviewed.
      - [ ] using the [concurrency 
checklist](https://github.com/apache/druid/blob/master/dev/code-review/concurrency.md)
 (Remove this item if the PR doesn't have any relation to concurrency.)
   - [ ] added documentation for new or modified features or behaviors.
   - [ ] a release note entry in the PR description.
   - [ ] added Javadocs for most classes and all non-trivial methods. Linked 
related entities via Javadoc links.
   - [ ] added or updated version, license, or notice information in 
[licenses.yaml](https://github.com/apache/druid/blob/master/dev/license.md)
   - [ ] added comments explaining the "why" and the intent of the code 
wherever would not be obvious for an unfamiliar reader.
   - [ ] added unit tests or modified existing tests to cover new code paths, 
ensuring the threshold for [code 
coverage](https://github.com/apache/druid/blob/master/dev/code-review/code-coverage.md)
 is met.
   - [ ] added integration tests.
   - [ ] been tested in a test Druid cluster.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to