Table 10. State Transitions for Events
|
|
.evt -> .xevt |
Before a message is processed by a workflow, it is renamed to have an ".xevt" extension so that if a crash occurs it will be possible on CIR restart to tell which messages were "in-process". |
.xevt -> Event deletion |
If a workflow processes an event with no errors the event is deleted from the disk. |
.paused -> .evt |
Every five minutes the queue directory is scanned for ".paused" files, if found, they are renamed to ".evt" and processed again. When the CIR begins processing a response group, it looks on the disk for any messages with a ".paused" extension. These Events were paused when the CIR was previously stopped. These events are renamed and reloaded and processed as normal ".evt" files. |
.xevt -> .paused |
If a transitory error occurs, (for example, if a database goes down) while an event is being processed it will be "paused" and reprocessed within five minutes. |
.evt -> .paused |
If a transitory error occurs before an event can be processed, it is "paused" by renaming to ".paused". Within five minutes, another attempt will be made at processing the event. |
.xevt -> failed event deletion |
If an event cannot be deleted after it has been processed, an error message is logged and an email is sent that warns the administrator of the impending re-processing of an event. This is will happen because when the server restarts, the ".xevt" event will be requeued as a ".retry.evt" event. |
.xevt -> .error |
If a workflow returns an error while processing an event, the event is given a ".error" extension. |
.xevt -> .failed |
If a non transitory error occurs while processing an event, the event is given a ".failed" extension. |
.xevt -> .retry.evt |
When the CIR begins processing a response group, it looks on the disk for any messages with a ".xevt" extension. These events were "in-process" when the CIR terminated abnormally so it cannot be determined whether or not they are directly responsible for the crash. To avoid discarding events that did not cause the crash, the events are requeued with a ".retry.evt" extension. However, if the server crashes while processing the ".retry.evt" event, it is possible to determine that the message h as already been party to one crash, which indicates that it may have caused the crash. This can also help to avoid infinite requeing of such events. |
.retry.evt -> .retry.xevt |
An event that may have previously caused a crash is renamed to have a "retry.xevt" extension before being reprocessed by a workflow. |
.retry.evt -> .crash |
An event that was party to two abnormal CIR terminations will be renamed to ".crash". |
retry.xevt -> .error |
An event that may have previously caused a crash, which then causes a workflow error is renamed to "*.error". |