The Monitor Server component produces three types of exceptions in WebSphere® Business Monitor.
The rolled back event will be iteratively processed and rolled back in an infinite scenario, which may cause the blocking of the Monitor Server. The reason for this behavior is to avoid processing the events that come after the event that caused the exception leading to an out-of-order event processing, which will result to the loss of sequence of event processing.
Alternatively, you can prevent the Monitor Server from being blocked by any runtime exception by changing the Exception Destination for the destination queue Monitor_Bus_Queue_Destination which is used by the Monitor Server to System instead of None. This way the events causing runtime exceptions will be ignored. In this case, it is the responsibility of the administrator to configure the WebSphere Business Monitor to either be blocked when a runtime exception occurs, to preserve data consistency and event sequencing, or to ignore the event that caused the error to avoid the blocking of the server but allow data inconsistency and the out of order of events. Refer to the topic named Changing the exception destination for the destination queue for the detailed steps of how to change the exception destination for the destination queue.
A special case for this behavior is implemented for the hard exceptions caused by processing the on time situation. As long as these situations are generated and owned by the Monitor Server and are independent from the runtime engine events, then there is no need to treat these exceptions in the same manner by forcing the Monitor server to retry processing the event and block the system. In this case the exceptions caused by processing on time situation events are handled differently as follows: The processing of the on time situation event is handled within the batch event processing cycle transaction boundary. Thus given that the processing of the on time situation event threw an exception, the batch of processed events are rolled back. Then the monitor server resets the last fire time value such that when the next on time event is created, it will initialize again the last fire time to the current monitor time. This has the effect of delaying the on time situation event to the next on time situation event interval, hoping that the events that will be processed in between will eliminate the cause of error.