Apama 10.11.3 | Building and Using Apama Dashboards | Dashboard Deployment | Managing the dashboard data server and display server | Controlling the update frequency
 
Controlling the update frequency
The correlator sends update events to the data server, display server, or any clients using the Scenario Service API (see also Scenario Service API) for all scenarios with output variables (for example, DataViews, including MemoryStore tables that expose DataViews using the exposeMemoryView or exposePersistentView schema options). These updates are sent whenever the values of fields or output variables in your scenarios change. If you have scenarios that update frequently, you might need to reduce the frequency of update events sent by the correlator.
You can adjust the settings per scenario definition or globally. The global value is used where a given scenario definition has no specific setting. The per-definition values always take precedence over the global values.
A ConfigureUpdates event consists of the following:
*scenarioId (type string): May be the empty string to modify the global values, or a definition's scenarioId.
*Configuration (type dictionary (string, string)): Configuration key and values. Key can be one of:
*sendThrottled (type boolean): Whether to send throttled updates (on the scenarioId.Data channel). The default is true.
*sendRaw (type boolean): Whether to send every update (on the scenarioId.Data.Raw channel). The default is true.
*throttlePeriod (type float): Throttle period in seconds. A zero value indicates no throttling. The default is 0.0.
*routeUpdates (type boolean): Whether to route Update events for the benefit of EPL files running in the correlator. The default is false.
*sendThrottledUser: (boolean): Whether to send throttled updates on a per-user channel. The default is false.
*sendRawUser (type boolean): Whether to send raw updates on a per-user channel. The default is false.
Those with a User suffix are suitable for using with only custom clients that use ScenarioServiceConfig.setUsernameFilter() on their service configuration.
For example, consider the following:
com.apama.scenario.ConfigureUpdates("DV_scenario1",
{"sendRaw":"true"})
com.apama.scenario.ConfigureUpdates("",{"sendRaw":"false",
"throttlePeriod":"0.1"})
com.apama.scenario.ConfigureUpdates("DV_scenario2",
{"sendRaw":"true"})
com.apama.scenario.ConfigureUpdates("DV_scenario3",
{"throttlePeriod":"1.0"})
The above examples configure DV_scenario1 and DV_scenario2 to send raw updates; DV_scenario3 to use a throttle period of 1 second; and all other scenarios to not send raw updates, and to use a throttle period of 0.1 seconds.
Earlier releases used the com.apama.scenario.SetThrottlingPeriod(x) event. Note that the use of the ConfigureUpdates events allows greater flexibility than the SetThrottlingPeriod event (which only controlled sending of throttled updates for all scenarios).
The use of com.apama.scenario.SetThrottlingPeriod(x) should be replaced with:
com.apama.scenario.ConfigureUpdates("", {"throttlePeriod":"x"})
Note that by default, routeUpdates is false, so any EPL that relies on Update (and other scenario control events) to be routed should route a ConfigureUpdates event for the scenarioIds it is interested in to route Updates.
The latest values are always used — thus it is not advisable for a client to send an event requesting (for example) raw updates and then undo this when it disconnects, as that will affect other clients. The recommendation is that the administrator should configure settings at initialization time.
Runtime performance of scenarios can be improved by setting sendRaw and routeUpdates to false and throttlePeriod to a non-zero value. In this case, the cost of an update is reduced (as the Update events are only generated when needed, and if throttling, they are only needed at most once every throttlePeriod).