WFLYEJB0043:A previous execution of timer is still in progress,skipping this overlapping scheduled execution at

Question

I am using jbpm 7.37 verison.We are using wildfly 14.0. Server abnormally gives below error just after a deployment of war files:

WARN  [org.jboss.as.ejb3.timer] (EJB default - 2) WFLYEJB0043: A previous execution of timer [id=6
9baf0d9-60b4-4775-982b-bf525682df3d timedObjectId=business-central.business-central.FileSystemDeleteWorker auto-timer?:tru
e persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@1ed2f93a initialExpiration=null intervalD
uration(in milli sec)=0 nextExpiration=Thu Apr 08 03:48:00 UTC 2021 timerState=IN_TIMEOUT info=null] is still in progress,
 skipping this overlapping scheduled execution at: Thu Apr 08 03:58:24 UTC 2021.

What could be the possible root cause for this issue? How to solve this issue? This issue mostl occruing on TEST environment.Please help.

Note: We have made custom REST APIs and deployed inside kie-server.war file.This issue causing my kie-server.war file to be unavailable for further use,so that our custom apis are not available and making application down. This is serious concern we are facing.Please help.

Answer 1

The deployment is scheduling an EJB timer on an interval that expires before JBoss moves into the started state. Since JBoss is in a suspended state until it finishes deploying everything, the timer can look to fire before it is allowed, thus once JBoss moves into the started state, you will see some warnings indicating that the timer was unable to invoke because JBoss had not finished deploying everything.

So these warnings can be ignored.

Root Cause: EJB 3.2 spec section [13.4.3 Timer Expiration and Timeout Callback Method] has a paragraph somewhat related to this topic:

In the event of a con-tainer crash or container shutdown, any single-event persistent timers that have expired during the inter- vening time before container restart must cause the corresponding timeout callback method to be invoked upon restart. Any interval persistent timers or schedule based persistent timers that have expired during the intervening time must cause the corresponding timeout callback method to be invoked at least once upon restart.