[
https://issues.jboss.org/browse/WFLY-8929?page=com.atlassian.jira.plugin....
]
Wolf-Dieter Fink updated WFLY-8929:
-----------------------------------
Steps to Reproduce:
Create a Simple Bean @Singleton and use a method like this:
@Schedule(second = "*/1", minute = "*", hour = "*",
persistent = true)
private void longRunning4parallelExecution() {
LOGGER.info("Start long running scheduled method");
int sec = 988;
LOGGER.info("sleeping " + sec + " milli seconds.");
try {
Thread.sleep(sec);
} catch (InterruptedException e) {}
LOGGER.info("Finished executing concurrent schedule");
}
The timer show often concurrent WARN messages and should stuck after a few minutes
running
Race condition if timers overlap due to long running execution and
short schedules if database persistence is used
------------------------------------------------------------------------------------------------------------------
Key: WFLY-8929
URL:
https://issues.jboss.org/browse/WFLY-8929
Project: WildFly
Issue Type: Bug
Components: EJB
Environment: Configure DB persistence for timers as file-persistence will not
have a persistence check for shouldRun to lock the timer execution.
Reporter: Wolf-Dieter Fink
Attachments: server-extract.log
If timers (here calendar timer) are running longer than scheduled, or the
schedule/processing get stuck do to thread or cpu bottleneck, it is possible that the
updates for persistence overlap.
The issue seems that the task(1) try to finish the timer and task(2) is about to start
but see the concurrency.
The DB is updated with the 'old' next timeout, but the internal Timer instance
will be updated with the next possible schedule due to a race condition between the two
threads updating the object.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)