You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had searched in the issues and found no similar issues.
What happened
The logic in Flink's source code: When high availability is used, unless manually configured with PipelineOptionsInternal.PIPELINE_FIXED_JOB_ID, the default is to generate jobId based on the cluster id.
When Dinky submits tasks to Kubernetes, the cluster id is the fixed task name, which results in the same jobId for the same task being executed each time.
When the HistoryServer retrieves results, it does not re-fetch jobIds that already exist, which prevents the retrieval of results for newly submitted tasks.
On the other hand, Dinky's JobRefreshHandler will overwrite the information of tasks that have failed/canceled in the HistoryServer with the same jobId as tasks that are currently running.
What you expected to happen
The jobId should change for each new instance of the submitted task
How to reproduce
Utilize the Flink Kubernetes cluster and configure high availability in the cluster settings, setting jobmanager.archive.fs.dir to the address specified by the HistoryServer.
Launch the HistoryServer to ensure it operates normally.
When submitting tasks to the Kubernetes application, it is observed that the job id for the same task remains fixed upon each submission.
->
The task jobs obtained by the HistoryServer do not update with the completion of each task.
The task statuses in the operations center all change to failed or canceled states in the HistoryServer, triggering alerts (even though the tasks are running normally), and refreshing is ineffective. Disabling the HistoryServer and then refreshing allows the task statuses to return to normal.
Search before asking
What happened
The logic in Flink's source code: When high availability is used, unless manually configured with PipelineOptionsInternal.PIPELINE_FIXED_JOB_ID, the default is to generate jobId based on the cluster id.
When Dinky submits tasks to Kubernetes, the cluster id is the fixed task name, which results in the same jobId for the same task being executed each time.
When the HistoryServer retrieves results, it does not re-fetch jobIds that already exist, which prevents the retrieval of results for newly submitted tasks.
On the other hand, Dinky's JobRefreshHandler will overwrite the information of tasks that have failed/canceled in the HistoryServer with the same jobId as tasks that are currently running.
What you expected to happen
The jobId should change for each new instance of the submitted task
How to reproduce
jobmanager.archive.fs.dir
to the address specified by the HistoryServer.->
Anything else
No response
Version
1.2.0
Are you willing to submit PR?
Code of Conduct
The text was updated successfully, but these errors were encountered: