-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
False
-
-
False
-
NEW
-
NEW
-
---
-
---
In a process with a boundary timer on a node that is defined with a repeatable timer (eg. R/PT10S), the TimerMappingInfo table is not getting updated properly. The scheduling happens through DefaultTimerJobInstance calling EjbSchedulerService.internalSchedule which bypasses the listeners responsible for creating the TimerMappingInfo entry.
In the log file, we can see the following warn message being logged as a side effect of this problem:
14:27:01,068 WARN [org.jbpm.services.ejb.timer.EjbSchedulerService] (EJB default - 1) Problem retrieving timer for uuid 2-1-HT-1: javax.ejb.NoSuchObjectLocalException: WFLYEJB0339: Timer for handle with timer id: 8da94d14-f1f5-4112-840d-4ef6765605f5, timedObjectId: kie-server.kie-server.EJBTimerScheduler is not active at org.jboss.as.ejb3@7.4.16.GA-redhat-00002//org.jboss.as.ejb3.timerservice.TimerHandleImpl.getTimer(TimerHandleImpl.java:103) at deployment.kie-server.war//org.jbpm.services.ejb.timer.EjbSchedulerService.getEjbTimer(EjbSchedulerService.java:115) at deployment.kie-server.war//org.jbpm.services.ejb.timer.EjbSchedulerService.getTimerJobInstance(EjbSchedulerService.java:102) at deployment.kie-server.war//org.jbpm.services.ejb.timer.EjbSchedulerService.scheduleJob(EjbSchedulerService.java:72) at deployment.kie-server.war//org.jbpm.process.core.timer.impl.GlobalTimerService.registerJobHandle(GlobalTimerService.java:172) at deployment.kie-server.war//org.jbpm.process.core.timer.impl.GlobalTimerService.scheduleJob(GlobalTimerService.java:118) at deployment.kie-server.war//org.jbpm.process.core.timer.impl.RegisteredTimerServiceDelegate.scheduleJob(RegisteredTimerServiceDelegate.java:68)
This is caused by the TimerMappingInfo table pointing to a non-existing timer after the rescheduling.
Database state after the timer is initially scheduled - this is a correct state:
jboss=# select id, timed_object_id, initial_date, timer_state from jboss_ejb_timer;
id | timed_object_id | initial_date | timer_state
--------------------------------------+-----------------------------------------+---------------------+-------------
8da94d14-f1f5-4112-840d-4ef6765605f5 | kie-server.kie-server.EJBTimerScheduler | 2025-05-06 14:26:51 | CREATED
(1 row)
jboss=# select id, externaltimerid, kiesessionid, processinstanceid, timerid, uuid from timermappinginfo;
id | externaltimerid | kiesessionid | processinstanceid | timerid | uuid
----+--------------------------------------+--------------+-------------------+---------+----------
1 | 8da94d14-f1f5-4112-840d-4ef6765605f5 | 2 | 1 | 1 | 2-1-HT-1
(1 row)
Database state after the new timer got created - this state is incorrect/broken:
jboss=# select id, timed_object_id, initial_date, timer_state from jboss_ejb_timer;
id | timed_object_id | initial_date | timer_state
--------------------------------------+-----------------------------------------+---------------------+-------------
ea69595c-d3be-42d1-97e1-5312c47ac728 | kie-server.kie-server.EJBTimerScheduler | 2025-05-06 14:27:01 | CREATED
(1 row)
jboss=# select id, externaltimerid, kiesessionid, processinstanceid, timerid, uuid from timermappinginfo;
id | externaltimerid | kiesessionid | processinstanceid | timerid | uuid
----+--------------------------------------+--------------+-------------------+---------+----------
1 | 8da94d14-f1f5-4112-840d-4ef6765605f5 | 2 | 1 | 1 | 2-1-HT-1
(1 row)
Note that the timermappinginfo.externaltimerid value points to the initial timer, not the new one that has been created after the rescheduling operation.
With the following two properties set, the problem becomes worse:
<property name="org.jbpm.ejb.timer.disable.linear.search" value="true"/>
<property name="org.jbpm.ejb.timer.disable.linear.remove" value="true"/>
With the linear search disabled, and the broken records in TimerMappingInfo, there is an increase in records in the jboss_ejb_timer table
