[
https://issues.apache.org/jira/browse/FLINK-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15452391#comment-15452391
]
Maximilian Michels commented on FLINK-4535:
-------------------------------------------
Hi [~jinyu.zj]! Just a few remarks:
{quote}
3. Check whether it is a duplicate registration by input resourceId, reject the
registration
{quote}
I think the RM should just perform the registration anyways but generate a new
{{InstanceID}} and send that back to the TaskExecutor with the registration
confirmation.
{quote}
5. Create the connection between resourceManager and taskExecutor, and ensure
its healthy based on heartbeat rpc calls between rm and tm ?
{quote}
You can skip that for now, we will deal with that in FLINK-4449.
I think for now it is ok to just let erroneous registration attempts time out
or send RegistrationResponse.Decline. The TaskExecutor is responsible for
retrying in case it doesn't get an answer in time or the registration gets
declined. Please have a look at {{RetryingRegistration}} and
{{ResourceManagerRegistration}}.
> ResourceManager registration with TaskExecutor
> ----------------------------------------------
>
> Key: FLINK-4535
> URL: https://issues.apache.org/jira/browse/FLINK-4535
> Project: Flink
> Issue Type: Sub-task
> Components: Cluster Management
> Reporter: zhangjing
> Assignee: zhangjing
>
> When TaskExecutor register at ResourceManager, it takes the following 3 input
> parameters:
> 1. resourceManagerLeaderId: the fencing token for the ResourceManager leader
> which is kept by taskExecutor who send the registration
> 2. taskExecutorAddress: the address of taskExecutor
> 3. resourceID: The resource ID of the TaskExecutor that registers
> ResourceManager need to process the registration event based on the following
> steps:
> 1. Check whether input resourceManagerLeaderId is as same as the current
> leadershipSessionId of resourceManager. If not, it means that maybe two or
> more resourceManager exists at the same time, and current resourceManager is
> not the proper rm. so it rejects or ignores the registration.
> 2. Check whether exists a valid taskExecutor at the giving address by
> connecting to the address. Reject the registration from invalid address.
> 3. Check whether it is a duplicate registration by input resourceId, reject
> the registration
> 4. Keep resourceID and taskExecutorGateway mapping relationships, And
> optionally keep resourceID and container mapping relationships in yarn mode.
> 5. Create the connection between resourceManager and taskExecutor, and ensure
> its healthy based on heartbeat rpc calls between rm and tm ?
> 6. Send registration successful ack to the taskExecutor.
> Discussion:
> Maybe we need import errorCode or several registration decline subclass to
> distinguish the different causes of decline registration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
