[
https://issues.apache.org/jira/browse/FLINK-31838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Pohl reassigned FLINK-31838:
-------------------------------------
Assignee: Matthias Pohl
> Move thread handling from DefaultMultipleComponentLeaderElectionService into
> DefaultLeaderElectionService
> ---------------------------------------------------------------------------------------------------------
>
> Key: FLINK-31838
> URL: https://issues.apache.org/jira/browse/FLINK-31838
> Project: Flink
> Issue Type: Sub-task
> Reporter: Matthias Pohl
> Assignee: Matthias Pohl
> Priority: Major
>
> While working on FLINK-31773 we noticed in the PR (see [comment
> #1|https://github.com/apache/flink/pull/22380#discussion_r1168724716] and
> [comment
> #2|https://github.com/apache/flink/pull/22380#discussion_r1168771139]) that
> there's a different notion of responsibility of the thread handling between
> the FLINK-24038 and the pre-FLINK-24038 implementation of the leader
> election. The latter one (i.e.
> {{{}DefaultLeaderElectionService{}}}) doesn't need to deal with where
> {{onGrantLeadership}} and {{onRevokeLeadership}} are called because those are
> called in a separate thread in the driver. The new implementation (i.e.
> {{{}DefaultMultipleComponentLeaderElectionService{}}}) has to call the
> {{onGrantLeadership}} and {{onRevokeLeadership}} methods itself when
> registering new contenders. This would happen in the main thread of the
> {{LeaderContender}} which is not suitable.
> {{DefaultMultipleComponentLeaderElectionService}} solves this by introducing
> its own threadpool.
> The separation of driver and contender in FLINK-31773 requires such a
> executionService in {{DefaultLeaderElectionService}} as well before going
> ahead with FLINK-31773.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
