There are a lot of customers who use the Event Collector API or perform select statements on the ec_pe_status directly to obtain various stats they require.

What was noticed was that when a process instance changes it's state, or when a process attribute was updated then the ec_pe_status table query did not reflect the change(s) made.

As the Stats Collector thread updates the ec_pe_status table (along with other tasks), investigation needs to take place in to what this thread was doing for the delay.

Lines of investigation should be along the following:-

- large number of entries in the ec_event_trigger table?
- latency between AMXBPM and the database?
- heavily fragmented EC database tables?

If these are all ok, then you need to look at the settings in the sc.properties file to make sure they are correct.
 

All supported platforms and versions

In version 4.1.0, Process instances are assigned to a particular node in Statistics Collector which improves querying performance and various other things.
However, this has subtly changed the way the Stats Collector (SC) behaves in a relatively low-volume environment.

The fix is to modify the following setting in sc.properties:
eventProcessorDefaultWait=10000

That should mean that SC checks for new work every 10 seconds on each node, rather than the default of 2 minutes. As a result, the ec_pe_status table is updated a lot quicker and therefore, no delay.

A delay is noticed when a process instance changes state or an attribute is updated. When querying the ec_pe_status table, the states are not reflective of the changes that have been made. The correct state eventually happens 2-4 minutes later.

eventProcessorDefaultWait is not referenced in any of the AMXBPM documentation set