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

Reply via email to