[5.4] add OverlappingStrategy for Schedule/Event

[fetzi]

The withoutOverlapping implementation in the Event class is not working in all cases. For example when the process gets killed, the cache entry is not removed and the scheduled command will not start again until the cache entry expires.

Therefore I've implemented an OverlappingStrategy Interface to be able to override the standard cache strategy. The interface specifies 3 methods:

• prevent: prevent overlapping for the current event's command (e.g. writes cache entry)
• reset: resets the overlapping strategy for the event's command (e.g. deletes cache entry)
• overlaps: checks if the event's command is overlapping with an already running command (e.g. checks if cache entry exists)

To be compatible with the current implementation I've added a CacheOverlappingStrategy that provides the same functionality as the current implementation.

[taylorotwell]

So this doesn't actually change the current behavior? What does your custom strategy look like?

[fetzi]

I check if the artisan command is running already by filtering the output of ps aux, I know that this solution is only valid for unix operating systems and therefore the current behavior should be kept.

But I can include my custom strategy in the PR if you want me to?

[alain-lf]

Would be nice to be able to modify the expiration of the mutex in configs

[alain-lf]

1440 = 24 hours.

Depending on your workload, if one of your servers goes down, you might not want to wait a full day for the key to expire and resume schedule.

[fetzi]

@alain-lf Adding the cache entry lifetime for the overlapping check to the config would be an option, but I think this would be to much change for a minor feature change.

And also a shorter cache entry lifetime does not solve the overlapping problem when the process dies, it only reduces the time until the process can be restarted. Maybe the ProcessOverlappingStrategy would be a solution fror you as well?

@taylorotwell what do you think about the config for the mutex cache entry liftetime?

[taylorotwell]

You wouldn't really want a global config item for this. It would be job specific.

[fetzi]

That's true, I will skip this for the PR because it is targeting the extensibility of the overlapping strategy. Is the PR ready for merging or do you need additional infos?

[fetzi]

@taylorotwell ?

[taylorotwell]

No need to keep pinging. I will eventually look at it.