Handling exceptions

Because the handling of exceptions is configured by the user in the monitor model (such as correlation matches exceptions and parent not found exceptions), soft exceptions are expected. The Monitor Server logs it, and an event is sent to the Monitor action services to be displayed in Alerts in the dashboards to inform the administrator of the occurrence of the exception. When a soft exception occurs, processing of other events continues normally.

Hard exceptions (or runtime exceptions) are thrown as a result of a runtime error while retrieving and processing the events of a monitor model. Because such an exception is not configured in the monitor model, it is not expected. This kind of exception is logged and traced in the log files. Events that cause a hard exception are rolled back, along with all of their triggered maps and situations. An event is sent to the Monitor action services and an alert such as an email is sent.

The processing of a rolled-back event is retried until it is successfully processed, which causes the IBM Business Monitor server to become blocked. New events that arrive then remain in the queue, which can lead to events being processing out of order.

You can prevent the IBM Business Monitor server from being blocked by any runtime exceptions by changing the exception destination for the Monitor_Bus_Queue_Destination destination queue from None to System. Then, events causing runtime exceptions are ignored. However, the administrator must configure IBM Business Monitor to either halt 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 nonsequential events.

A special case for this behavior is implemented for hard exceptions caused by processing an on-time situation. As long as these situations are generated and owned by the IBM Business 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 IBM Business 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.

The processing of the on-time situation event is handled within the batch event processing cycle transaction boundary. Given that the processing of the on-time situation event threw an exception, the batch of processed events is rolled back. Then IBM Business Monitor server resets the last fire time value such that when the next on-time event is created, it initializes again the last fire time to the current IBM Business Monitor server time. This action delays the on-time situation event to the next on-time situation event interval, and the events that are processed during this interval might eliminate the cause of the error.

If the WebSphere Application Server locks up, the state of some events is set to in doubt. The IBM Business Monitor server cannot determine if in-doubt events were successfully processed. So, if a found exception is logged, an event is emitted to the Monitor action services so that an alert is sent. The administrator must then determine if these events are to be processed again or deleted.