Details
New Feature
Resolved
Major
Description
Currently the JobExecutor can only be exchanged by subclassing it and overwrite the implementation. This is for example necessary for ACT-34 in Websphere environments, but as well if you want to implement your own load balancing or execution strategy.
It should be an interface, but for backward compatibility I would suggest an empty abstract class. The current implementation will be moved to "DefaultJobExecutor".
For the JobExecutor a management interface during runtime would be interesting to:
- stop/start the job executor
- adjust parameters (like thread pool count or the like)
A typical use case would be to implement an own retry strategy (e.g. first retry after 1 minute, next after 10 minutes, next after 1 hour, ...), especially with asynchronous tasks and service tasks to external services. This could be hooked in by a custom implementation of the JobExecutor, but should be as easy to implement as possible. Maybe we should provide a sample to do this.
Discussed the management interface further, another required feature:
At the moment I guess it is sufficient to filter due jobs in the JobExecutor, because it is an exceptional case. The downside of it is that it has a bad performance, especially if you stop a process definition with a lot of instances and jobs, because the jobs are queried from the database and ignored all the time.
To improve performance we would need an additional query, which is more invasive (and work).
I would propose to split implementation now into