You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by "Misagh Moayyed (Jira)" <ji...@apache.org> on 2022/11/16 11:10:00 UTC

[jira] [Resolved] (SYNCOPE-1709) Persist Jobs' current status in the database to support multi-node deployments

     [ https://issues.apache.org/jira/browse/SYNCOPE-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Misagh Moayyed resolved SYNCOPE-1709.
-------------------------------------
    Resolution: Fixed

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