feature/KOJO-186 | kojo_job_table documentation and example configurations#109
feature/KOJO-186 | kojo_job_table documentation and example configurations#109alexberryman wants to merge 5 commits into5.xfrom
Conversation
| Real-world use cases for Kōjō and instructions for getting Kōjō up and running in your project can be found at [KojoFitness](https://github.com/neighborhoods/KojoFitness). | ||
|
|
||
| ## Configuring Kōjō | ||
| The `kojo_job_table` database table and the `\Neighborhoods\Kojo\Api\V1\Job\Type\ServiceInterface::getNewJobTypeRegistrar` Kōjō API client provide ways to control the scheduling behavior of Kōjō workers. |
There was a problem hiding this comment.
| The `kojo_job_table` database table and the `\Neighborhoods\Kojo\Api\V1\Job\Type\ServiceInterface::getNewJobTypeRegistrar` Kōjō API client provide ways to control the scheduling behavior of Kōjō workers. | |
| The `kojo_job` database table and the `\Neighborhoods\Kojo\Api\V1\Job\Type\ServiceInterface::getNewJobTypeRegistrar` Kōjō API client provide ways to control the scheduling behavior of Kōjō workers. |
There was a problem hiding this comment.
I meant kojo_job_type and got my T's mixed up.
| ## Configuring Kōjō | ||
| The `kojo_job_table` database table and the `\Neighborhoods\Kojo\Api\V1\Job\Type\ServiceInterface::getNewJobTypeRegistrar` Kōjō API client provide ways to control the scheduling behavior of Kōjō workers. | ||
|
|
||
| Each column in the `kojo_job_table` has a specific purpose |
There was a problem hiding this comment.
| Each column in the `kojo_job_table` has a specific purpose | |
| Each column in the `kojo_job` table has a specific purpose |
| - `worker_uri`: Class which will be created for the job | ||
| - `worker_method`: Method of `worker_uri` class that is called when a job is run | ||
| - `can_work_in_parallel`: Defines if multiple instances of job can be worked at the same time across all execution environments | ||
| - `default_importance`: Defines the priority of the job. Jobs with a higher importance will get scheduled first when resources are constrained |
There was a problem hiding this comment.
Nit: They're being worked in that order, I might change this wording to something like "defining the order in which jobs are worked", maybe with "if there's resource contention, lower priority jobs may experience a delay in being worked" parenthetically
| - `default_importance`: Defines the priority of the job. Jobs with a higher importance will get scheduled first when resources are constrained | ||
| - `cron_expression`: [crontab](https://crontab.guru/) formatted expression of how often the job will be added to the schedule, or null if the job is supposed to be dynamically scheduled | ||
| - `schedule_limit`: Number of concurrent jobs allowed to be in a `working` state at the same time. | ||
| - `schedule_limit_allowance`: Number of jobs allowed to be in a `waiting` state at the same time. |
There was a problem hiding this comment.
schedule_limit_allowance is not used anywhere in the code, and there are several job types in LS that demonstrably disprove this
| - `cron_expression`: [crontab](https://crontab.guru/) formatted expression of how often the job will be added to the schedule, or null if the job is supposed to be dynamically scheduled | ||
| - `schedule_limit`: Number of concurrent jobs allowed to be in a `working` state at the same time. | ||
| - `schedule_limit_allowance`: Number of jobs allowed to be in a `waiting` state at the same time. | ||
| - `is_enabled`: Turn the job on and off. |
There was a problem hiding this comment.
I might add something here about how this affects statically- vs dynamically-scheduled jobs differently. For the former, it won't schedule any more, but if anything was already scheduled, it'll still be worked. For the latter, you'll get an exception from the WorkerService's job scheduler if you try to schedule a disabled job type
| - `schedule_limit_allowance`: Number of jobs allowed to be in a `waiting` state at the same time. | ||
| - `is_enabled`: Turn the job on and off. | ||
| - `auto_complete_success`: Once the job is no longer running, assume it completed successfully, even if the worker didn't `requestCompleteSucess` | ||
| - `auto_delete_interval_duration`: Defines how long `complete_success` and `complete_failed` jobs should remain in the `kojo_job` table using [ISO 8601 Duration String format](https://en.wikipedia.org/wiki/ISO_8601#Durations) |
Co-Authored-By: Przemyslaw Mucha <32273336+mucha55@users.noreply.github.com>
Co-Authored-By: Przemyslaw Mucha <32273336+mucha55@users.noreply.github.com>
kojo_job_table documentation and example configurations