You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Matthias Pohl (Jira)" <ji...@apache.org> on 2023/04/18 11:24:00 UTC
[jira] [Updated] (FLINK-31838) Move thread handling from DefaultMultipleComponentLeaderElectionService into DefaultLeaderElectionService
[ https://issues.apache.org/jira/browse/FLINK-31838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthias Pohl updated FLINK-31838:
----------------------------------
Description:
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.
> 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
> 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)