[
https://issues.apache.org/jira/browse/FLINK-9936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16567850#comment-16567850
]
ASF GitHub Bot commented on FLINK-9936:
---------------------------------------
GJL commented on a change in pull request #6464: [FLINK-9936][mesos] WIP
URL: https://github.com/apache/flink/pull/6464#discussion_r207456451
##########
File path:
flink-runtime/src/main/java/org/apache/flink/runtime/resourcemanager/ResourceManager.java
##########
@@ -894,17 +900,21 @@ public void grantLeadership(final UUID
newLeaderSessionID) {
// clear the state if we've been the leader
before
if (getFencingToken() != null) {
- clearState();
+ clearStateInternal();
}
setFencingToken(newResourceManagerId);
slotManager.start(getFencingToken(),
getMainThreadExecutor(), new ResourceActionsImpl());
- getRpcService().execute(
- () ->
+ prepareLeadershipAsync()
+ .exceptionally(t -> {
+ onFatalError(t);
+ return null;
+ })
+ .thenRunAsync(() ->
// confirming the leader
session ID might be blocking,
-
leaderElectionService.confirmLeaderSessionID(newLeaderSessionID));
+
leaderElectionService.confirmLeaderSessionID(newLeaderSessionID),
getRpcService().getExecutor());
Review comment:
I don't understand why it's needed to check for leadership in
`tryAcceptLeadership`. The zk `LeaderElectionService` already does that:
```
if (leaderLatch.hasLeadership()) {
// check if this is an old confirmation call
synchronized (lock) {
if (running) {
if
(leaderSessionID.equals(this.issuedLeaderSessionID)) {
confirmedLeaderSessionID =
leaderSessionID;
writeLeaderInformation(confirmedLeaderSessionID);
}
} else {
LOG.debug("Ignoring the leader session
Id {} confirmation, since the " +
"ZooKeeperLeaderElectionService
has already been stopped.", leaderSessionID);
}
}
} else {
LOG.warn("The leader session ID {} was confirmed even
though the " +
"corresponding JobManager was not
elected as the leader.", leaderSessionID);
}
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Mesos resource manager unable to connect to master after failover
> -----------------------------------------------------------------
>
> Key: FLINK-9936
> URL: https://issues.apache.org/jira/browse/FLINK-9936
> Project: Flink
> Issue Type: Bug
> Components: Mesos, Scheduler
> Affects Versions: 1.5.0, 1.5.1, 1.6.0
> Reporter: Renjie Liu
> Assignee: Gary Yao
> Priority: Blocker
> Labels: pull-request-available
> Fix For: 1.5.3, 1.6.0
>
>
> When deployed in mesos session cluster mode, the connector monitor keeps
> reporting unable to connect to mesos after restart. In fact, scheduler driver
> already connected to mesos master, but when the connected message is lost.
> This is because leadership is not granted yet and fence id is not set, the
> rpc service ignores the connected message. So we should connect to mesos
> master after leadership is granted.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
