Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
While working on SOLR-5823, i tried to write a test using ZkController.forceOverSeer() to force the overseer to change from one node to another (to prove my code could properly detect the new overseer)
The test failed spectacuarly, because after calling forceOverSeer() the end result was that Overseer obejcts on both ZkControllers wound up being active.
I'm not well versed on the leader/overseer election stuff – but from what i can tell poking arround in the code of forceOverSeer(), compared to the code involved in OversearchElectionContext, it seems like forceOverSeer() doesn't relaly do anything to ensure that the "old" overseer ever "stops". miller's comments in SOLR-5823 seem to re-affirm that.
We should make forceOverSeer() work safely, or we should eliminate it.
Attachments
Issue Links
- relates to
-
SOLR-5823 Add utility function for internal code to know if it is currently the overseer
- Resolved