Internal implementation: Running Tasks On One Server

[peco8]

Hello, I'm just curious about this method onOneServer to support laravel task scheduling for multi-region environments with k8s. Can anybody explain to me how this is implemented internally?

Yes, I understand it uses supported cache drivers but it would be great if I can find more details. (I use database cache driver.)
Thank you.

[mikeydevelops]

So by default Laravel asks you to configure cron job for php artisan schedule:run to be ran every minute.

1. When you schedule an event/task with onOneServer it creates an Event instance and sets a public property $onOneServer to true.
2. When the command is run, it collects all events/tasks that should run at that specific time.
3. If it happens to run an event/task requiring to be run on only one server, it uses the default cache driver to create a so called mutex.
4. A mutex is a unique lock (In computer science, a lock or mutex is a synchronization primitive: a mechanism that enforces limits on access to a resource when there are many threads of execution.)
5. The mutex needs a name and each server generates that name from concatenating these parts.
   1. The word framework.
   2. The value of the global constant DIRECTORY_SEPARATOR which is different for each OS.
      1. / for Linux based OSes
      2. \ for DOS based OSes
   3. The word schedule
   4. Dash -
   5. The sha1 hash of the cron job expression for the event (the time definition you gave the command i.e everyFiveMinutes()) and the command itself you used i.e telescope:prune
   6. So the name of the mutex for this command $this->schedule('telescope:prune')->everyFiveMinutes() is framework/schedule-db2d6048a17360683ee66cdefda6d338e02b2139
6. Then the mutex is tried to be acquired if the cache store sees there is a lock with the given name it will say nay and the task will be skipped. in case of the database driver, a new record is added for the mutex in cache_locks table.
7. And finally when the task completes, the mutex is removed form the cache store.

This method however assumes, every server's clock is synchronized.

[khaledsbuyme]

@mikeydevelops
Hi,
How does this work well with php artisan cache:clear? I mean during deployment, we usually run php artisan cache:clear. Will this affect the implementation since after running cache:clear the original entry will be removed from the cache store while the command is still running on the server and then another server might run it? No

[mikeydevelops]

Mutex locks are not cleared with cache:clear command. They are never supposed to be persistent. A task defines a mutex and gives it a time to live or ttl. When that task completes, or if the time expires, that lock is removed automatically.

[khaledsbuyme]

@mikeydevelops
I checked the entries in a specific redis store (ex: below)
stage.4322e19.nb.0001.euc1.cache.amazonaws.com:6379[5]> KEYS *
..
...
.
..
..
211) "laravel_database_laravel_cache_framework/schedule-fbb7751e44d3975b646fb2e87563b9767e3656681433"
212) "laravel_database_laravel_cache_framework/schedule-f1db7a364dc94e98cc1b8f4c3be604bb7071849f1452"
213) "laravel_database_laravel_cache_framework/schedule-2e9ce9e72b5252e0502159ea7ce38378b8eeea281444"
214) "laravel_database_laravel_cache_framework/schedule-7a73a7e9e487ddaa5d2f14d01f18a2e0d8dac7941443"
215) "laravel_database_laravel_cache_framework/schedule-7a73a7e9e487ddaa5d2f14d01f18a2e0d8dac7941438"
216) "laravel_database_laravel_cache_framework/schedule-f1db7a364dc94e98cc1b8f4c3be604bb7071849f1450"

And after running php artisan cache:clear I saw that all the keys were deleted

stage.4322e19.nb.0001.euc1.cache.amazonaws.com:6379[5]> KEYS *
NO records were returned

Can you explain further?

[mikeydevelops]

Yeah, sorry for the confusion. I answered on the context that the original issue was using database cache driver. With it, there is a separate table for mutex called cache_locks. When the cache is cleared from the database, this table is not being reset.

Appears you are correct. This is the intended functionality for cache xdrivers other than database. A workaround for it would be to setup another redis connection to another database on the same redis server and maybe call it locks or mutex in config/database.php. for example the cache will be in redis db 0 and the mutex will be in redis db 1. Then in config/cache.php, you find the redis connection config and add a 'lock_connection' => 'mutex', to the config.

// config/cache.php

'redis' => [
    'driver' => 'redis',
    'connection' => 'cache',
+    'lock_connection' => 'mutex',
],

Then when laravel is making locks it checks for this lock_connection key and uses it to make the lock instead of the default connection.