[
https://issues.apache.org/jira/browse/SYNCOPE-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17633910#comment-17633910
]
ASF subversion and git services commented on SYNCOPE-1709:
----------------------------------------------------------
Commit f1cd7ccec1382a696d9e09b3454a227de9f55558 in syncope's branch
refs/heads/master from Misagh Moayyed
[ https://gitbox.apache.org/repos/asf?p=syncope.git;h=f1cd7ccec1 ]
SYNCOPE-1709: Persist Jobs' current status in the database to support
multi-node deployments (#390)
Co-authored-by: Francesco Chicchiriccò <[email protected]>
> 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)
