[ https://issues.apache.org/jira/browse/SYNCOPE-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Francesco Chicchiriccò updated SYNCOPE-1709: -------------------------------------------- Fix Version/s: 2.1.13 3.0.1 (was: 2.1.12) (was: 3.0.0) > Persist Jobs' current status in the database to support multi-node > deployments > ------------------------------------------------------------------------------- > > Key: SYNCOPE-1709 > URL: https://issues.apache.org/jira/browse/SYNCOPE-1709 > Project: Syncope > Issue Type: Improvement > Affects Versions: 2.1.12, 3.0.0-M2 > Reporter: Misagh Moayyed > Assignee: Misagh Moayyed > Priority: Major > Fix For: 2.1.13, 3.0.1 > > > When jobs, particularly (long-running) reports, are scheduled/asked to run > and there are multiple Syncope core nodes available in the cluster, the > current method of obtaining the job status via Spring and Quartz fails to > report back the status accurately, specially when the job bean is scheduled > on one node and the status check query is performed on another. > To support this scenario, job status details would be persisted in the > backend database in a new table, and the job engine would be responsible to > add/update/delete details in this table. Status query checks would then look > into this table to report back current status instead of obtaining the status > from the Spring bean responsible for execution. > it was discussed that the initial changeset would go into master and be > targeted to Syncope v3, and then may be backported to 2.x pending feasibility > and complication. -- This message was sent by Atlassian Jira (v8.20.10#820010)