Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix #2860 #2207 notification of loss of leadership and easy cancel #4125

Merged
merged 1 commit into from
May 19, 2022
Merged

fix #2860 #2207 notification of loss of leadership and easy cancel #4125

merged 1 commit into from
May 19, 2022

Conversation

shawkins
Copy link
Contributor

@shawkins shawkins commented May 6, 2022 •
edited by manusa
Loading

Description

Fix #2860
Fix #2207

This attempts to clear up some of the threading and logic related to leader election. When using the start method it removes the need to hold a thread, and all other tasks are handled through the common pool. This is not fully non-blocking as the lock operations - get, create, update do not yet expose non-blocking calls.

This also refined the Utils scheduling methods to ensure that task execution does not overlap and adds the ability to supply the completion future and a delay supplier to match the needs of the leader loop logic.

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • Feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change
  • Chore (non-breaking change which doesn't affect codebase;
    test, version modification, documentation, etc.)

Checklist

  • Code contributed by me aligns with current project license: Apache 2.0
  • I Added CHANGELOG entry regarding this change
  • I have implemented unit tests to cover my changes
  • I have added/updated the javadocs and other documentation accordingly
  • No new bugs, code smells, etc. in SonarCloud report
  • I tested my code in Kubernetes
  • I tested my code in OpenShift

@shawkins shawkins requested review from manusa and rohanKanojia May 6, 2022 13:27
@shawkins shawkins force-pushed the leader branch 7 times, most recently from dadbc86 to d043c43 Compare May 11, 2022 17:40
@shawkins shawkins added this to the 6.0.0 milestone May 18, 2022
@shawkins @manusa
fix fabric8io#2860 fabric8io#2207 notification of loss of leadership …
b8927ab 
…and easy cancel

also removing holding a thread when using start
and adding more jitter support
and a cleanup of the retry logic
@sonarqubecloud
Copy link

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 7 Code Smells

81.9% 81.9% Coverage
0.0% 0.0% Duplication

@manusa manusa merged commit 042c77b into fabric8io:master May 19, 2022
@manusa manusa mentioned this pull request Aug 8, 2022
Merged
11 tasks
@XComp XComp mentioned this pull request Jan 16, 2024
Closed
XComp added a commit to XComp/flink that referenced this pull request Jan 19, 2024
@XComp
[FLINK-34007][k8s] fabric8io LeaderElector is created with every new …
b672877 
…#run() call

v5.12.4 allowed us to reuse the LeaderElector. With v6.6.2 (fabric8io/kubernetes-client#4125) this behavior changed. One LeaderElector can only be used until the leadership is lost.
XComp added a commit to XComp/flink that referenced this pull request Jan 23, 2024
@XComp
[FLINK-34007][k8s] fabric8io LeaderElector is created with every new …
60250b5 
…#run() call

v5.12.4 allowed us to reuse the LeaderElector. With v6.6.2 (fabric8io/kubernetes-client#4125) this behavior changed. One LeaderElector can only be used until the leadership is lost.
XComp added a commit to XComp/flink that referenced this pull request Jan 23, 2024
@XComp
[FLINK-34007][k8s] fabric8io LeaderElector is created with every new …
d903e8a 
…#run() call

v5.12.4 allowed us to reuse the LeaderElector. With v6.6.2 (fabric8io/kubernetes-client#4125) this behavior changed. One LeaderElector can only be used until the leadership is lost.
XComp added a commit to XComp/flink that referenced this pull request Jan 23, 2024
@XComp
[FLINK-34007][k8s] fabric8io LeaderElector is created with every new …
bb55379 
…#run() call

v5.12.4 allowed us to reuse the LeaderElector. With v6.6.2 (fabric8io/kubernetes-client#4125) this behavior changed. One LeaderElector can only be used until the leadership is lost.
XComp added a commit to XComp/flink that referenced this pull request Jan 23, 2024
@XComp
[FLINK-34007][k8s] fabric8io LeaderElector is created with every new …
f1f440c 
…#run() call

v5.12.4 allowed us to reuse the LeaderElector. With v6.6.2 (fabric8io/kubernetes-client#4125) this behavior changed. One LeaderElector can only be used until the leadership is lost.
XComp added a commit to XComp/flink that referenced this pull request Jan 26, 2024
@XComp
[FLINK-34007][k8s] fabric8io LeaderElector is created with every new …
4519e46 
…#run() call

v5.12.4 allowed us to reuse the LeaderElector. With v6.6.2 (fabric8io/kubernetes-client#4125) this behavior changed. One LeaderElector can only be used until the leadership is lost.
XComp added a commit to XComp/flink that referenced this pull request Jan 26, 2024
@XComp
[FLINK-34007][k8s] fabric8io LeaderElector is created with every new …
2628fa1 
…#run() call

v5.12.4 allowed us to reuse the LeaderElector. With v6.6.2 (fabric8io/kubernetes-client#4125) this behavior changed. One LeaderElector can only be used until the leadership is lost.
An ITCase is added to cover the scenario where the leadership is lost.
XComp added a commit to XComp/flink that referenced this pull request Jan 31, 2024
@XComp
[FLINK-34007][k8s] fabric8io LeaderElector is created with every new …
9a9e2d9 
…#run() call

v5.12.4 allowed us to reuse the LeaderElector. With v6.6.2 (fabric8io/kubernetes-client#4125) this behavior changed. One LeaderElector can only be used until the leadership is lost.
An ITCase is added to cover the scenario where the leadership is lost.
XComp added a commit to XComp/flink that referenced this pull request Jan 31, 2024
@XComp
[FLINK-34007][k8s] fabric8io LeaderElector is created with every new …
88c0d68 
…#run() call

v5.12.4 allowed us to reuse the LeaderElector. With v6.6.2 (fabric8io/kubernetes-client#4125) this behavior changed. One LeaderElector can only be used until the leadership is lost.
An ITCase is added to cover the scenario where the leadership is lost.
XComp added a commit to apache/flink that referenced this pull request Feb 1, 2024
@XComp
[FLINK-34007][k8s] fabric8io LeaderElector is created with every new …
927972f 
…#run() call

v5.12.4 allowed us to reuse the LeaderElector. With v6.6.2 (fabric8io/kubernetes-client#4125) this behavior changed. One LeaderElector can only be used until the leadership is lost.
An ITCase is added to cover the scenario where the leadership is lost.
XComp added a commit to XComp/flink that referenced this pull request Feb 1, 2024
@XComp
[FLINK-34333][k8s] fabric8io LeaderElector is created with every new …
c7a1b9f 
…#run() call (cherry-picked from FLINK-34007)

v5.12.4 allowed us to reuse the LeaderElector. With v6.6.2 (fabric8io/kubernetes-client#4125) this behavior changed. One LeaderElector can only be used until the leadership is lost.
An ITCase is added to cover the scenario where the leadership is lost.
XComp added a commit to XComp/flink that referenced this pull request Feb 5, 2024
@XComp
[FLINK-34333][k8s] fabric8io LeaderElector is created with every new …
03ea2a4 
…#run() call (cherry-picked from FLINK-34007)

v5.12.4 allowed us to reuse the LeaderElector. With v6.6.2 (fabric8io/kubernetes-client#4125) this behavior changed. One LeaderElector can only be used until the leadership is lost.
An ITCase is added to cover the scenario where the leadership is lost.
XComp added a commit to XComp/flink that referenced this pull request Feb 7, 2024
@XComp
[FLINK-34333][k8s] fabric8io LeaderElector is created with every new …
7509d68 
…#run() call (cherry-picked from FLINK-34007)

v5.12.4 allowed us to reuse the LeaderElector. With v6.6.2 (fabric8io/kubernetes-client#4125) this behavior changed. One LeaderElector can only be used until the leadership is lost.
An ITCase is added to cover the scenario where the leadership is lost.
XComp added a commit to apache/flink that referenced this pull request Feb 13, 2024
@XComp
[FLINK-34333][k8s] fabric8io LeaderElector is created with every new …
87560b7 
…#run() call (cherry-picked from FLINK-34007)

v5.12.4 allowed us to reuse the LeaderElector. With v6.6.2 (fabric8io/kubernetes-client#4125) this behavior changed. One LeaderElector can only be used until the leadership is lost.
An ITCase is added to cover the scenario where the leadership is lost.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@manusa manusa manusa approved these changes

@rohanKanojia rohanKanojia Awaiting requested review from rohanKanojia

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
6.0.0
2 participants
@shawkins @manusa