Skip to content
This repository has been archived by the owner on Jul 16, 2021. It is now read-only.

[PROPOSAL] Scheduled Events Drivers #342

Closed
tedslittlerobot opened this issue Dec 19, 2016 · 3 comments
Closed

[PROPOSAL] Scheduled Events Drivers #342

tedslittlerobot opened this issue Dec 19, 2016 · 3 comments

Comments

@tedslittlerobot
Copy link

More than happy to draft and PR - i thought i'd float the idea first, and pick an implementation before getting too deep into coding it.

In essence, it would be nice to be able to customise how the command scheduler's overlapping works. it currently stores a file in the storage directory. for multiple load-balanced servers, it would be nice if it could go somewhere else - a common resource to all servers, like a database or redis? a fringe benefit of using database / redis is that you wouldn't need to hash the command to make the mutex file name, so would make debugging commands a lot easier if there are tasks that are taking too long (which would be a possible solution to laravel/framework#12456). and would let you see what commands are running at that time.

There may be other things that i have not considered, but essentially, it writes the lock, performs the command, deletes the lock, and writes the output to wherever it was told to. it does this in a single process call.

My first thought would be to have a driver-based setup for scheduled events (similar to every other driver based thing in laravel) - something like:

  • create an OverlappingCommandVerifier contract - has 3 methods - checkIsRunning($command, $expression), and lockCommand($command, $expression) and unLockCommand($command, $expression)
  • Remove the mutexPath method from Schedule\Event, move to an implementation of the contract. (NB. This would slightly change the existing mutexPath implementation to break it up into 2 Processes either side of the actual scheduled process, rather than one chained Process. (if this is a problem, then i'm sure we can come up with an alternative interface to the one above))
  • Add implementation for redis / database (with a publishable migration for the database option)

Like i said, i thought i'd post it as an idea before getting too deep into an implementation of it. comments welcome.

@themsaid
Copy link
Member

In 5.4 we use Cache based mutex, see laravel/framework#16196

@tomschlick
Copy link

Your proposal and mine are pretty similar #69

Thankfully it should be fixed for 5.4 as @themsaid explained 👍

@tedslittlerobot
Copy link
Author

ah, then, problem solved!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants