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:

  • 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.
  • The receiving object’s destination is itself blocked waiting and its queues are full.
  • 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):

  1. 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.
  2. 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.
 
ecs_tec/event_notification_and_blocking_architecture.txt · Last modified: 2007/02/09 18:55 by teofana
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki