0

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.

Neha
  • 109
  • 3
  • 15
  • @James R. Perkins Could you help here. – Neha Apr 08 '21 at 10:45
  • The error indicates the issue - a timer was running and then it tried to run again. If this is ok then you can ignore the message. Otherwise you need some code to prevent this. – stdunbar Apr 08 '21 at 19:42
  • This error makes my war file unavailable, so all my custom apis are not found.Making application down.What code should i do to prevent this ? – Neha Apr 09 '21 at 04:41
  • Generally, something [like this](https://stackoverflow.com/questions/14402068/ejb-schedule-wait-until-method-completed) is the standard way but it's not clear if this will work in your environment. – stdunbar Apr 09 '21 at 17:16
  • I suggest you share your code and the timeout method as well as the bean that houses it. This is a timer overlap that your server warns you that it will not execute AGAIN until current execution stops. You might be working in a team where everybody deploy out of their own accord and thus you ended up in a situation where somebody registered a timeout/scheduled method and didnt tell others. – alegria Jan 12 '22 at 08:15

1 Answers1

0

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.

Chavan Abhijeet
  • 41
  • 1
  • But this causing my deplyoment unavailable and services are down,What could be the possible solution ? – Neha Apr 14 '21 at 04:45
  • This shouldn't make your services unavailable. this is simply a container managed lock that controls access on singleton methods. In Wildfly it is implemented in such a way that it won't run twice if the last execution hasn't finished. – alegria Jan 12 '22 at 08:12