Hi:
In my opinion, what you are describing is a normal phenomenon.
When executing the cube build job, kylin will add the task of each step in the
job into a map. The FetcherRunner will periodically fetch the tasks that can be
executed from the map and add them to the JobPool. If it is found that the
number of jobs in JobPool has reached the configuration value
("kylin.job.max-concurrent-jobs"), then this fetcher will return directly and
wait for the fetcher in the next cycle.
That is to say, the task fetched by the FetcherRunner is a step task of a cube
build job, which may belong to the previous job submitted by you, or the latter
job submitted by you, so these build jobs may be executed alternately.
For related knowledge, you can refer to kylin's job scheduler related articles:
https://blog.bcmeng.com/post/kylin-job.html
<https://blog.bcmeng.com/post/kylin-job.html>
> 在 2021年4月23日，12:50，xatax <rohan...@gmail.com> 写道：
>
> I have obeserved that when the "kylin.job.max-concurrent-jobs" properties is
> used for a cluster configuration and set to for e.g. lets say value 1. Then
> for a given cube building job cluster, during a cube build if another cube
> build request is submitted the currently running job is set to pending and
> Kylin starts running the new job on the same cluster. Then again it might
> pause the running job and any step and then return to the execution of the
> first job. This is usually observed after the first step but can be random.
>
> Is this expected behavior?
>
> The good thing is ultimately both jobs run to success.
>
> Please share any knowledge on this.
>
> thanks!
>
> --
> Sent from: http://apache-kylin.74782.x6.nabble.com/
