You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@flink.apache.org by spoon_lz <sp...@126.com> on 2022/08/24 03:34:14 UTC

Doubt about the RUNNING state of the job

     When we run a job, we can see the running status of the job in the 'Running Job List' on the flink web ui. Normally, it will be in the state of ‘RUNNING’.
     But when the job is just started, 'RUNNING' The status of the job does not mean that the job is processing the data correctly, it may still be applying for TM resources, which may last for several minutes in the case of a large degree of parallelism (it may even be stuck due to not being able to apply for resources).
     So why not add new ones The state represents the state in which the job is actually processing data.




Re: Doubt about the RUNNING state of the job

Posted by Hangxiang Yu <ma...@gmail.com>.
Actually, Every operator/subtask will have its own status just behind the
'RUNNING' status on the flink UI.
The status may be 'CREATED', 'DEPLOYING', 'INITING', 'RUNNING' and so on as
you could see some status in [1].
Different operators/subtasks may have different status.
After all operators/subtasks turn to 'RUNNING'. then we think the job
actually starts processing data.

[1]
https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/internals/job_scheduling/

On Wed, Aug 24, 2022 at 11:35 AM spoon_lz <sp...@126.com> wrote:

>      When we run a job, we can see the running status of the job in the
> 'Running Job List' on the flink web ui. Normally, it will be in the state
> of ‘RUNNING’.
>      But when the job is just started, 'RUNNING' The status of the job
> does not mean that the job is processing the data correctly, it may still
> be applying for TM resources, which may last for several minutes in the
> case of a large degree of parallelism (it may even be stuck due to not
> being able to apply for resources).
>      So why not add new ones The state represents the state in which the
> job is actually processing data.
>
>
>

-- 
Best,
Hangxiang.