TaskManager的Slot的释放时机

[johnjlong <jo...@163.com>]

各位大佬好，请教一个问题。
我根据ResourceID主动释放TM的链接的时候，我发现TM对应的Slots仅仅是标记为free。
而其真正是释放却要等到JobMaster主动cancel整个ExecuteGraph的时候，此时会逐个调用每个定点所在的slot的TM的cancel方法。
但是此时相关联的TM已经close掉，触发了rpc超时，默认20s。然后slot才会被释放。


我的问题是：为什么不在调用TaskExecutor的cancelTask之间判断下TM是否存活，如果不存活就直接走cancel的流程，不用等rpc超时后，才进行下一步？？？


附上日志截图：


| |
johnjlong
|
|
johnjlong@163.com
|
签名由网易邮箱大师定制

Re: TaskManager的Slot的释放时机

[Zhilong Hong <zh...@gmail.com>]

Hello, johnjlong:

TaskExecutor#cancel是RPC调用，不包含TM是否存活的信息。TM是否存活是由Heartbeat
Service来负责检测的，目前heartbeat.timeout配置项 [1]
的默认值为50s。而RPC调用的超时配置项akka.ask.timeout [2]
的默认值为10s。如果想要尽快检测到TM丢失的情况，可以将这两个配置项的值调小，但这有可能会导致集群或作业不稳定。

关于降低heartbeat timeout时长社区目前已有讨论，具体可以参考：[3] 和 [4]

[1]
https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/deployment/config/#heartbeat-timeout
[2]
https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/deployment/config/#akka-ask-timeout
[3] https://issues.apache.org/jira/browse/FLINK-23403
[4] https://issues.apache.org/jira/browse/FLINK-23209

Sincerely,
Zhilong

On Tue, Jan 25, 2022 at 10:06 AM johnjlong <jo...@163.com> wrote:

> 各位大佬好，请教一个问题。
> 我根据ResourceID主动释放TM的链接的时候，我发现TM对应的Slots仅仅是标记为free。
>
> 而其真正是释放却要等到JobMaster主动cancel整个ExecuteGraph的时候，此时会逐个调用每个定点所在的slot的TM的cancel方法。
> 但是此时相关联的TM已经close掉，触发了rpc超时，默认20s。然后slot才会被释放。
>
>
> 我的问题是：为什么不在调用TaskExecutor的cancelTask之间判断下TM是否存活，如果不存活就直接走cancel的流程，不用等rpc超时后，才进行下一步？？？
>
> 附上日志截图：
>
> johnjlong
> johnjlong@163.com
>
> <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=johnjlong&uid=johnjlong%40163.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fqiyelogo%2FdefaultAvatar.png&items=%5B%22johnjlong%40163.com%22%5D>
> 签名由网易邮箱大师 <https://mail.163.com/dashi/dlpro.html?from=mail81>定制
>