Details
-
Sub-task
-
Status: Closed
-
Critical
-
Resolution: Done
-
1.9.0
Description
Recently, we encountered a case that one TaskExecutor get stuck during launching on Yarn (without fail), causing that job cannot recover from continuous failovers.
The reason the TaskExecutor gets stuck is due to our environment problem. The TaskExecutor gets stuck somewhere after the ResourceManager starts the TaskExecutor and waiting for the TaskExecutor to be brought up and register. Later when the slot request timeouts, the job fails over and requests slots from ResourceManager again, the ResourceManager still see a TaskExecutor (the stuck one) is being started and will not request new container from Yarn. Therefore, the job can not recover from failure.
I think to avoid such unrecoverable status, the ResourceManager need to have a timeout on starting new TaskExecutor. If the starting of TaskExecutor takes too long, it should just fail the TaskExecutor and starts a new one.
Attachments
Issue Links
- fixes
-
FLINK-16215 Start redundant TaskExecutor when JM failed
- Open
- is blocked by
-
FLINK-18620 Unify behaviors of active resource managers
- Closed
- is related to
-
FLINK-18229 Pending worker requests should be properly cleared
- Closed
-
FLINK-15456 Job keeps failing on slot allocation timeout due to RM not allocating new TMs for slot requests
- Closed
-
FLINK-19171 K8s Resource Manager may lead to resource leak after pod deleted
- Closed
- links to
- mentioned in
-
Page Loading...