Task #335
closed
Long running task - schedule by other task
100%
Description
- how to configure and persist dependent task
- how to execute dependent task
One possible solution is store dependent task as common task job property and extend basic AbstractLongRunningTaskExecutor functionality (find and execute dependent tasks).
Test and doc will be included.
Files
Related issues
Updated by Jan Helbich over 7 years ago
- Status changed from New to In Progress
- Assignee changed from Ondřej Kopr to Jan Helbich
Updated by Jan Helbich over 7 years ago
Looking around the internet for solution on job chaining with Quartz I found two acceptable solutions:
1. using JobChainingJobListener- job listener shipped with Quartz
- requires persistence and manual setting up of JobListners
- according to Qartz FAQ, JobListeners seems to be perfomance bottlenecks (http://www.quartz-scheduler.org/documentation/faq.html#FAQ-scale)
- persist dependent job name, class and group in inital job's properties (JobDataMap)
- straightforward implementation, dependent job info is stored within already created data structure (*scheduler.entity.IdmLongRunningTask)
According to few community answers and Quartz FAQ, going with 2nd options has good results. I also vote for choosing the second approach with jobdatamap.
Updated by Jan Helbich over 7 years ago
- creating loops in job chain will be forbidden
- valid chain: A -> B -> C
- invalid chain: A -> B -> A
Updated by Jan Helbich over 7 years ago
- Status changed from In Progress to Needs feedback
- Assignee changed from Jan Helbich to Ondřej Kopr
After some struggles I've implemented the BE part of the assignment. It's still a bit rough on the edges and needs a bit of refactoring and polishing, because I've tried multiple approaches, but generally it should be done.
I just need to make sure the task workflow execution process is correct. Let's say we have four tasks, T1, T2, T3 and T4. The task chain is as follows:
T1 -> T2 -> T3
T1 -> T4
I've implemented the task processing order as recursive and synchronous, thus the tasks are proccessed in the following order:
1. T1
2. T2 (following T1)
3. T3 (following T2, we are executing tasks "depth first")
4. T4 (following T1)
Can you provide feedback on this, please? Thx
Updated by Jan Helbich over 7 years ago
- Status changed from Needs feedback to In Progress
- Assignee changed from Ondřej Kopr to Jan Helbich
After short discussion:
T1 -> T2 -> T3
T1 -> T4
will execute as follows:
1. T1
----|----> T2 (following T1)
------------|---> T3
----|----> T4 (following T1)
Therefore T2 and T4 are executed asynchronously, T3 is executed after T2 synchronously (T2 waits for T3 to complete).
I've successfully refactored the original solution for parallel execution and removed original task ordering.
All BE tests (core-impl and acc modules) are running OK.
Updated by Radek Tomiška over 7 years ago
- Target version changed from Citrine (7.3.0) to Diamond (7.4.0)
Updated by Jan Helbich about 7 years ago
- Assignee changed from Jan Helbich to Radek Tomiška
Somehow I did not find time to finish the implementation of FE, BE should be done though.
Updated by Vít Švanda about 7 years ago
- Target version deleted (
Diamond (7.4.0))
Updated by Radek Tomiška about 7 years ago
- Target version set to Emerald (7.5.0)
Updated by Radek Tomiška about 7 years ago
- Status changed from In Progress to Needs feedback
- Assignee changed from Radek Tomiška to Ondřej Kopr
- % Done changed from 0 to 90
I've implemented:
- dependent task trigger
- added @DisallowConcurrentExecution
- to long running task table on FE
-- added bulk task cancel action
-- added pagination and sort
Documentation
https://wiki.czechidm.com/devel/dev/configuration/task-scheduler#tasks_scheduler
https://wiki.czechidm.com/devel/dev/architecture/events#longrunningtaskexecutedependentprocessor
Commit:
https://github.com/bcvsolutions/CzechIdMng/commit/101c4b46bc03b36338aeb9a30dcc3e7f867cc22c
Could you pls do a test and review
Updated by Radek Tomiška about 7 years ago
- Related to Task #647: Scheduled Task sorting in table added
Updated by Ondřej Kopr about 7 years ago
- File same_name.png same_name.png added
- Assignee changed from Ondřej Kopr to Radek Tomiška
- % Done changed from 90 to 100
- when create one LRT that depend on itself, task will call itself for endless, can be this round cycles resolved?
- nice label in selectbox are name task but when i created two tasks from same type but different parameters i can't choose right task, is isn't big problem, because after save i see what task i pick, but i can imagine that for someone will be this unbeatable problem.
Otherwise dependent task works perfectly, random order for many dependents task is ok. Thanks for resolve HH ticket. Documentation is awesome and test was included.
If round cycles can be resolved, please close this ticket. Thank you.
Updated by Radek Tomiška about 7 years ago
- Status changed from Needs feedback to Closed
Thx for feedback:
- cycles are ok - its possible to configure "endless" task.
- in the nice label is shown task type and description, so it's possible to define same task with different description. I've added info component, when trigger is created to know with parameters are used.