Overlapping commands

[gdbonino]

Hello!
I have a situation which I don't think is a bug but which I find strange and which is a change that was introduced on f37c976.

I have the following real case with two jobs:

1. Job1, which runs every hour at minute 5 (5 * * * *)
2. Job2, which runs every hour at minute 10 (10 * * * *)

Generally Job1 finishes quickly, but in certain situations it can last more than 5 minutes, overlapping with the start of Job2.

What I expected and how the original library worked (I've been using it for several years) is that Job2 would start normally.

But now the lock is general at scheduler level. So Job2 doesn't start until Job1 finishes.

The lock should exist but at the level of each job so that the same job is not running twice at the same time, but here they are two different jobs.

Thank you very much for the work to maintain this library!

[Chris53897]

Hi @gdbonino
f37c976#diff-ccf4f09b31223f9dc855a7941ff76ce91ab6a301739bb8fbd13b6f4f63533dafR136

Option a) If the lock should be on Job-Level. The code could be moved here.
f37c976#diff-6a3339ee89ca3b3efd96f69de424c09a6de954e99dd5666f6447345fa2bf1728R67

With a Lock-Key (Possible Key = 'command_'.$command->id)
https://symfony.com/doc/current/components/lock.html

Option b) Make the actual lock optional? With opt-out

But what are possible side effects?

[gdbonino]

Hi @Chris53897! Thanks for the quick reply.

I don't know exactly how the library used to work at the code level, but I do know that before the lock was not at the scheduler level but at the job level. And today the lock at the job level is still there because when a job is running in the admin panel a little padlock is set.

The expected from the library would be that the scheduler is always executed (the lock f37c976#diff-ccf4f09b31223f9dc855a7941ff76ce91ab6a301739bb8fbd13b6f4f63533dafR136 should be removed) and make sure that if a job is being executed (it has the "little padlock") it is not executed so that there is no overlapping of the same job. This is one of the great advantages that this library has over putting the jobs directly in the OS cron.

I don't know if it would be necessary to use the Lock component since you already have info at the database level that the job is running.

Option B in my case is not an alternative because of what I mentioned before. I need to have the lock at the job level. Without this lock, I think it would be better to go directly against the OS cron :(

[Chris53897]

I would love to work on this. But i do not have for this in the near future. Sorry