[
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)