we have a record in the act_ru_timer_job table
id_ | rev_ | type_ | lock_exp_time_ | lock_owner_ | exclusive_ | execution_id_ | process_instance_id_ | proc_def_id_ | scope_id_ | sub_scope_id_ | scope_type_ | scope_definition_id_ | retries_ | exception_stack_id_ | exception_msg_ | duedate_ | repeat_ | handler_type_ | handler_cfg_ | custom_values_id_ | create_time_ | tenant_id_ |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
95b674cc-205a-11eb-9ed6-eeee0aff4d09 | 1 | timer | NULL | NULL | TRUE | 95b674ca-205a-11eb-9ed6-eeee0aff4d09 | 959fdf1f-205a-11eb-9ed6-eeee0aff4d09 | NPS_SURVEY:22:dda7e3b7-1fae-11eb-a358-eeee0aff2673 | NULL | NULL | NULL | NULL | 3 | NULL | NULL | 04:59.6 | NULL | trigger-timer | {"activityId":"sid-4D1EE1E5-B951-4AEA-9CA4-C0737A7C499F"} | NULL | 04:59.6 | |
this record is past due and seemingly not being grabbed by flowable to be processed. we see the query to find jobs to execute looks like this:
select
RES.*
from ACT_RU_TIMER_JOB RES
where SCOPE_TYPE_ is null
and DUEDATE_ <= $1
and LOCK_OWNER_ is null LIMIT $2 OFFSET $3
$1 being the current time and we are not able to find where $2 or $3 are coming from. The query correctly returns the record without the LIMIT and OFFSET filters. There is currently a high volume in ACT_RU_TIMER_JOB (10 million records). Do you think this is an issue with the volume never being able to get to this and many other records? What else could potentially cause a timer to not be triggered?