This repository has been archived by the owner on Oct 18, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added onOneServer option to short run commands #8
Added onOneServer option to short run commands #8
Changes from 2 commits
5e20686
f024ce7
8cd3229
53f51f9
9797876
a6ddf4b
7b3d679
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why
60
? Does the Laravel framework code also uses this value?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The framework was using 3600 but I thought 60 seconds as this whole package is about sub minute tasks. I was thinking it should use
$this->pendingShortScheduleCommand->frequencyInSeconds()
so the expiration lasts only as long as the time between checks. However this should also depend on if you care about overlaps or not.
If it's too short could be an issue for some and same if it's too long. I assume the frameworks assumption no task will run for more than an hour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, let's leave it at 60.
Should we also have to clean up this file when starting the loop? Right now, if we were to abort the loop at the wrong time, the file would stay, keeping to lock longer than it needs to be there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean in the situation the short-schedule:run is killed or dies then when it starts again that the command will be stuck because if the cache key is set? I have not experienced this. I am not 100% sure the running command actually terminates at the same time as as the loop.
So short-schedule:run can stop and I think the process that was running can still run and finish. It just will not be called again.
Worst case the key will expire in 1 minute. So in theory it should start running on one sever after 60 seconds in worst case scenario.