berg223 commented on PR #24371:
URL: https://github.com/apache/pulsar/pull/24371#issuecomment-2953722178
> @berg223 Regarding some other ExtensibleLoadManagerImpl related tests (in
ExtensibleLoadManagerImplTest and in ServiceUnitStateChannelTest), one detail
is about inconsistencies in how the test code changes the primary/leader by
closing LeaderElectionImpl. LeaderElectionImpl should stop election operations
after it's closed, but making that change will break tests. The draft change is
#23995.
>
> I was planning to handle to problem by introducing an internal control
interface for LeaderElection
>
> ```
> public interface LeaderElectionControl {
> void releasePossibleLeaderRole();
> void skipElections();
> void resumeElections();
> }
> ```
>
> tests could use this instead of using hacks which they currently rely on.
Releasing leadership could be useful also in production code later if there
would be a need to let go of the leadership role on one broker. However, this
would be initially targeted for tests and not exposed. the WIP changes are in
[master...lhotari:pulsar:lh-fix-LeaderElectionImpl-close-wip](https://github.com/apache/pulsar/compare/master...lhotari:pulsar:lh-fix-LeaderElectionImpl-close-wip)
We are spying the case that our broker cannot connect to metadata store and
the leadership hasn't change. The expected behavior should be that the
loadbalanceManager of leader will reassign the bundles to other broker. So we
won't use `LeaderElectionControl` in this case.
However, we can consider the clear and resuseable way to spy this case
similiar to `LeaderElectionControl`. But I don't have a good idea for now.
--
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]
