Skip to content

feature/KOJO-186 | kojo_job_table documentation and example configurations#109

Open
alexberryman wants to merge 5 commits into5.xfrom
feature/KOJO-186
Open

feature/KOJO-186 | kojo_job_table documentation and example configurations#109
alexberryman wants to merge 5 commits into5.xfrom
feature/KOJO-186

Conversation

@alexberryman
Copy link
Contributor

kojo_job_table documentation and example configurations

@alexberryman alexberryman marked this pull request as ready for review March 5, 2020 17:56
@alexberryman alexberryman requested a review from mucha55 as a code owner March 5, 2020 17:56
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice link 👍

alexberryman and others added 2 commits March 5, 2020 13:24
Co-Authored-By: Przemyslaw Mucha <32273336+mucha55@users.noreply.github.com>
Co-Authored-By: Przemyslaw Mucha <32273336+mucha55@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants