Bugzilla – Full Text Bug Listing
| Summary: | Job Scheduling Service (Multi-Tenant Support) | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Gunnar Wagenknecht <gunnar> |
| Component: | gyrex | Assignee: | Gunnar Wagenknecht <gunnar> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | andreas.mihm |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 329792, 339081 | ||
| Bug Blocks: | |||
We should investigate Quartz as a default implementation for such a service. Fixed and released. Well, it was already in M7. But we modified the implementation to be based on contexts. Basically, you can now do context#get(IJobManager.class) or context#get(IScheduleManager.class) to get a hold of the context specific job/schedule manager. There are OSGi services to get such a manager including context lookup. The basic concept is that (when persisting) the scheduleId is prefixed with a hash of the context path. For the ScheduleManager the implementation is separated into a ScheduleStore. This allows to lookup and manage schedules independent from the context. For jobs the implementation is still wrapped into JobManager. We should look at separating it as well for 1.1. For now, any Jobs API is provisional. |
We need a scheduling service in Gyrex which is capable of scheduling multiple jobs at specific times and/or intervals for one or many tenants. The idea is to have something like a "job schedule plan". This plan is stored in the cloud (eg., database, ZooKeeper, whatever). Each context may then be associated to a particular plan. Basically, the plan defines which jobs (a) must be executed when (b) for which context (c). The assumption is that each plan is responsible for at most one context. Example: Plan "System Jobs" - context: "/" - jobs: - "Metrics export & reset" every 2 hours - other non-tenant specific jobs... Plan "Jobs for Tenant SuperSeller" - context: "/superseller" - jobs: - "Import products" every day at 2 a.m. UTC time - "Synchronize inventory for master inventory" every 2 hours Plan "Jobs for Tenant SuperSeller UK Store" - context: "/superseller/uk" - jobs: - "Remove stale carts" every Monday at 3 a.m. UK time - "Optimize index" at 4 a.m. UK time every morning Eventually the "context" association isn't necessary at the plan level but can be configured on a per job basis. Later on, we might need a concept of plan "templates" to make setup of new configurations easier. A plan processing engine monitors all plans and schedules the jobs. By scheduling the jobs are inserted into queues but not executed directly. This may add a latency from the scheduling time to the actual execution time. A set of workers will monitor the queues and execute jobs one by one. The number of queues is not limited. A job configured in a plan and/or a plan itself can specify a preferred queue. This can be used to implement dedicated queues for high-priority jobs or tenant-reserved queues (in order to allow for low-latency execution times). The worker which execute the actual job need to have the job provider installed and started. We should use DS in order to allow lazy activation of job bundles. In the future, we might be able live with really small workers which install job providers on-demand using p2. But that's *post* 1.0.