Troubleshooting
Problem
Counteracting unwanted multiple reprocessing of events through checking flag field before committing to the full Policy process.
Cause
In high load environments it is possible for the EventReader to be running with a backlog of events in the EventQueue and for there to be multiple copies of an event held therein. This leads to events being reprocessed multiple times even when event flag fields are employed to prevent event recapture once it has been processed.
Resolving The Problem
Event flagging (please see the TechNote "Event flagging" [link below]) is useful for preventing multiple recapture of events (please see the TechNote "Avoiding unwanted event reprocessing" [link below]), but if multiple recapturing of the event occurs before the event is even processed for the first time the chance for multiple reprocessing remains.
One part of the solution is to use a flag field value to indicate that the event has started to undergo processing without having to wait for the entire Policy process to complete. But still there is the potential for copies of the events to exist in the EventReader EventQueue. One can deal with these with the UpdateEventQueue() Policy function - please see the TechNote "Removing duplicate event records from EventQueue with UpdateEventQueue" [link below].
However, there is a further situation where the copy of the event has moved on to the EventProcessor EventQueue and is outside the scope of the UpdateEventQueue() Policy function. This is addressed by ensuring the EventReader processes duplicate events in a single thread manner through using EventLocking against a unique field (for example: Identifier - please see the TechNote "Using EventLocking to help prevent multiple event reprocessing" [link below]) and configure the Policy to check the flag field value of the actual event in the ObjectServer and determine if processing should continue or not. For example:
- ID = "ID_"+ @Serial +"_"+ @StateChange +": ";
WP = "Start";
Log(1,ID+WP);
WP = "RemoveDuplicates";
Log(2,ID+WP);
EventReaderName = "OMNIbusEventReader";
Filter = "Serial = "+ @Serial;
IsDelete = True;
NumDeletedEvents = UpdateEventQueue(EventReaderName, Filter, NULL, IsDelete);
Log(3,ID+WP+" Number of duplicate events deleted from EventQueue: "+NumDeletedEvents);
WP = "CheckProcessingGo";
DataType = "MyObjServ_AlertsStatus";
Filter = "Identifier = '"+ @Identifier +"'";
GoNoGo = GetByFilter(DataType, Filter, false);
Log(3,ID+WP+": GoNoGo ImpactFlag: "+ GoNoGo[0].ImpactFlag);
If(GoNoGo[0].ImpactFlag in (2, 3))
{
- Log(ID+WP+": !!! Event already processed - exiting !!!");
Exit();
ElseIf(GoNoGo[0].ImpactFlag == 1)
{
- WP = "MarkEventImpacting";
Log(2,ID+WP);
@ImpactFlag = 2;
Log(3,ID+WP+": @ImpactFlag: "+ @ImpactFlag);
ReturnEvent(EventContainer);
...
- main portion of the Policy
Else
{
- Log(ID+WP+": !!! Event GoNoGo.ImpactFlag value: "+ GoNoGo[0].ImpactFlag +" not within expected range- exiting !!!");
Exit();
The above can be greatly reduced by removing extraneous logging and declaring parameters directly within the action functions. Please note that, if one were to set this up as a user defined (or custom) function, the Exit() action would only exit the user defined function and not the Policy process. To address this one would set a variable in the user defined function to indicate that the Policy process is to exit and then test this variable upon return to the Policy and act appropriately. Please see the TechNote "Exit() action within User Defined Function in Impact Policy Language" [link below].
Related Information
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg21675015