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 <johnjl...@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 > johnjl...@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>定制 >