A discussion of Web GUI's eventviewer.refresh.mode and its possible values

For Web GUI event lists, there are two steps in querying the datasource to list and update the event list.
1) Get the list of all Serials (SerialList) that match the filter, regardless of the StateChange. This is to get the current snapshot of the events in the datasource.
2) Get the details of the events (EventsList) that have been inserted or updated (where server.init has eventviewer.refresh.mode:1) or, after StateChange (i.e. delta update).
The gathered event's detail (2) needs to match the event's Serial (1) before the event can be added into the event list.

Normally, the Event Viewer will auto-refresh every 60 seconds, where on the next refresh the data caches will have expired and new data will be fetched from the datasource. There is a risk when a user manually triggers a refresh at the edge of the 60 second interval, at the same time as an event insert/update at the datasource within the same split second. The Serial list request is retrieved from the cache (cache not yet expired), while the event details are retrieved from the datasource (cache expired). Hence the SerialList does not have the event but the EventsList does, and so the event is excluded from the event list. For a high rate of events fed into the datasource, eventviewer.refresh.mode with mode "1" or "2" is recommended. Mode "1" is suitable for EventList cache disabled, and mode "2" is for when the EventList cache is enabled.

The reason for the mode "1" is the StateChange keeping its value in seconds. With a high event rate or an event storm, the possibility of the events feeding into the datasource in the same second that WebGUI requests an update from the datasource is high. By querying the events including those with the last StateChange timestamp, this will pick up the missed event.

The Serial list is the master list of the EventList. Any events from event details query that do not exist in the Serial list will be removed from the Event List. On the next refresh, the event details query will
have updated the StateChange timestamp that excluded the previously removed events. This combination of actions has the potential to cause events to go "missing". Mode "2" fixes this by overlapping the StateChange timestamp to subset the Serial list cache so that the previously removed events will still get retrieved on the next events list query.

For a low rate of events, the default eventviewer.refresh.mode:0 is recommended for both cache settings. Since the majority of our customers have an event throughput which we would class as low, this is the default value out of the box.

The behaviour described above is valid from fix pack 12 and is introduced with the APAR fix IV99878.