2

Whenever my application runs php artisan schedule:run and successfully schedules some jobs onto any of my queues, it creates a cache entry for itself in the following format:

laravel:framework/schedule-{SCHEDULE_HASH} where SCHEDULE_HASH is a random 32 character string, I'd understand if this cache key held some meaningful data but it only ever holds b:1; as its value.

What is the purpose of this cache value? As far as I'm aware, as soon as a call to schedule finishes we don't really care what happened as my process runner is set to re-run it in 60 seconds time to see if any new jobs need to be scheduled.

This is currently spamming my redis cache with hundreds of keys and I'd like to resolve it if possible.

The only thing I can possibly think is that when schedule:run is ran, then Running scheduled command: '/usr/local/bin/php' artisan job:name > '/dev/null' 2?&1 maybe the latter half is somehow using Redis as its storage destination and then piping a new cache value of 1 there, any help would be much appreciated.

UPDATE: I'm wondering if what I'm seeing is actually a cache mutex https://laravel.com/api/5.5/Illuminate/Console/Scheduling/Mutex.html as I'm using the onOneServer function. The only thing is, even after my jobs finish the mutex is not released.

Scheduled task:

$schedule->command('shop:calculate_remaining_work', [$shop->id])
    ->cron('*/5 * * * *') // per 5 minutes
    ->onOneServer()
    ->withoutOverlapping();

I'd expect the mutex to be released once the command finishes running, but this is not the case, the mutex remains in the cache for the full 1440 minutes

Halfpint
  • 3,967
  • 9
  • 50
  • 92
  • 1
    Yes as you suspect in your edit, this is a Mutex used to prevent the scheduler from re-running a job which is already running. If you change your cache driver, you'll see that the mutex will then appear in your new caching platform. – Joe Oct 18 '18 at 14:14
  • The thing that's confusing me is that even after the scheduled job finishes, the mutex is not being cleared – Halfpint Oct 18 '18 at 14:18
  • Hmmm by default `withoutOverlapping` passes an `$expiresAt` value of `1440` (in `/vendor/laravel/framework/src/Illuminate/Console/Scheduling/Event.php' ) – Joe Oct 18 '18 at 14:22
  • That's all very well and good, but 1440 minutes is far too long, especially if I want to ensure that this job is only processed by one server every three minutes. I'll update my question with the specifics – Halfpint Oct 18 '18 at 14:28

1 Answers1

5

https://laravel.com/docs/5.7/scheduling

In your call to withoutOverlapping() you can pass a cache expiry value in minutes.

$schedule->command('emails:send')->withoutOverlapping(10);
Joe
  • 4,618
  • 3
  • 28
  • 35
  • 1
    Perfect, cheers Joe. Massive oversight by me, although it is annoying that I have to force myself to use `withoutOverlapping` in conjunction with `onOneServer` to control the cache expire time. From the docs it sounded like `onOneServer` should release the mutex after the task completes but that wasn't the case for me – Halfpint Oct 18 '18 at 14:40