...
...
...
| Table of Contents |
|---|
Support for this was added first in SIL Engine™ 3.0.8 version but jobs were not made persistent - they didn't survive Jira restarts. We added this behavior in SIL Engine™ 4.0; it is a major change you requested and we felt obliged to implement. And because this mechanism is more powerful than the old services one, we replaced completely the services with this one.
...
Changes in 4.0
We improved this area a lot:
- Starting with SIL Engine™ 4.0, the jobs are persistent and survive Jira restarts.
- Old services are now removed. Scheduler is the only one that provides job scheduling now. Jobs previously defined over services will be moved on scheduler.
- Keys of the scheduled jobs have changed, and previous rules are not in place.
- Jobs were made cluster-aware, and we ensure now that a job is run just once in that cluster.
- Jobs do not preserve uniqueness based on path+arguments anymore. You will need to re-verify that you are not re-scheduling the same job multiple times now.
| Note | ||
|---|---|---|
| ||
| There's just one change that matters, and we cannot stress this enough: persistence of the jobs. |
Sources Of Incompatibility
We performed some customer interviews to see how these routines are used before modifying them. We rank the risk of incompatibility as being low, but since we cannot rule out the possibility, all we have to do is list what incompatibilities you may encounter.
Keys of Scheduled Jobs
If you relied on the key to extract information, such as the path and/or arguments of the job, this represents a source of incompatibility. However, our customer interviews only showed a basic usage of the scheduler, so the risk of incompatibilities is very, very low. Keep in mind that the key has no meaning other than identifying a certain job.
...
Because of the concern of ever-spawning jobs, we added a condition that if the file path and the arguments were the same, and you are re-scheduling a job with those characteristics, we would delete the previous job and schedule a new one. Turns out that it was a false concern and that customers understood the importance of not defining too many jobs.
We lifted this restriction in this version. If you relied on re-scheduling jobs like above, you are advised to review your architecture and ensure that your job is scheduled just once.
The risk of incompatibility is a little greater here, however not much greater. To mitigate this risk, we have created the getScheduledJobKeysByScript() routine that provides access to the key of a scheduled job. You may search for the script prior of scheduling one, and if found, you have the option to cancel it (delete) and reschedule a new job, or simply not to start the same job again.