This shows you the differences between the selected revision and the current version of the page.
| ecs_tec:event_notification_and_blocking_architecture 2007/02/06 19:51 | ecs_tec:event_notification_and_blocking_architecture 2007/02/09 18:55 current | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ===== Event Notification and Blocking Architecture ===== | ===== Event Notification and Blocking Architecture ===== | ||
| - | Since a typical ECA contains a complex graph of interconnected event-processing SystemObjects, there are bound to be times when a receiving object cannot accept a new event. Reasons include some of the following: | + | Since a typical ECA contains a complex graph of interconnected event-processing ''SystemObjects'', there are bound to be times when a receiving object cannot accept a new event. Reasons include some of the following: |
| * Slow, extensive processing must be done in the receiving object, for example, a statistical correlation filter may involve extensive computation and/or acessing outside resources such as a database. | * Slow, extensive processing must be done in the receiving object, for example, a statistical correlation filter may involve extensive computation and/or acessing outside resources such as a database. | ||
| Line 7: | Line 7: | ||
| * The receiving object may be a destination waiting on a slow device external to the ECS. | * The receiving object may be a destination waiting on a slow device external to the ECS. | ||
| - | Therefore, it is critical that the logical interconnections between objects implement strict policy decisions when an upstream object cannot receive the next event. At present, two policies have been implemented for SystemObjects (via the contained EventProcessor): | + | Therefore, it is critical that the logical interconnections between objects implement strict policy decisions when an upstream object cannot receive the next event. At present, two policies have been implemented for ''SystemObjects'' (via the contained EventProcessor): |
| - | - NEVER_DISCARD: don’t allow additional submit operations to this object when queue capacity has been reached, thus blocking at least the submitting SystemObject. This policy is designed to never lose or discard an event. | + | - **NEVER_DISCARD:** don’t allow additional submit operations to this object when queue capacity has been reached, thus blocking at least the submitting SystemObject. This policy is designed to never lose or discard an event. |
| - | - NEVER_BLOCK: this policy will allow submit operations on this object even when queue capacity is full, never waiting. However, prior events or the current event will probably be discarded after the destination queue has reached its capacity. | + | - **NEVER_BLOCK:** this policy will allow submit operations on this object even when queue capacity is full, never waiting. However, prior events or the current event will probably be discarded after the destination queue has reached its capacity. |