[
https://issues.apache.org/jira/browse/SLING-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-2990:
------------------------------------
Affects Version/s: Commons Scheduler 2.3.4
> race condition in scheduler could cause tasks to be lost
> --------------------------------------------------------
>
> Key: SLING-2990
> URL: https://issues.apache.org/jira/browse/SLING-2990
> Project: Sling
> Issue Type: Bug
> Components: Commons
> Affects Versions: Commons Scheduler 2.3.4
> Reporter: Amichai Rothman
>
> In QuartzScheduler.java, binding a task/job checks if the scheduler is null
> and then either registers the service reference or adds it to a list for
> later registration. When the scheduler is activated all items on the list are
> registered and the list is cleared.
> All accesses to the list are properly synchronized, but the scheduler null
> check is not, so they are not done atomically together - there may be a race
> condition here that can cause a task to be lost: if the scheduler is checked
> and found to be null, then a context switch occurs and the scheduler is
> activated and processes the list, and then the original thread resumes and
> adds the task to the list, then the task will remain unprocessed in the list
> and never be registered.
> The same thing might happen inversed with unbinding tasks/jobs.
> btw the bind/unbind methods are duplicated for jobs and tasks, so it might be
> nicer to extract the common implementation and delegate to it with a job/task
> parameter. Then there will be less places to apply the fix in :-)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
