Event Lifecycle

This article describes the lifecycle of a server event. Events generated in Agents and Iotellect Clients have simpler lifecycles with fewer stages.

  • A system component identifies the need to fire an event during its operation. For example, if a Device Driver loses contact with the hardware it is supposed to connect with, it will attempt to fire an info event in the Iotellect context of the Device.

  • Permissions of the context generating the event are checked. If its permissions do not allow firing this type of event in the target context, event generation fails.

  • If a Prefilter Expression is defined, it is evaluated. If it returns false, the event will be omitted.

  • If a Deduplication ID Expression is defined, it is evaluated and should return an event deduplication ID. The system tries to find another event with the same deduplication ID. If a matching event is found, the current event is dropped, but the occurrence counter of the original event is increased.

  • The event is enriched with additional user-defined data.

  • If the event is defined as persistent, it is saved to the event history. An event cannot be made permanent if it's not already defined as such (most events are permanent). However, the "time to live" of an event (its expiration time) can be changed. This is done by modifying the Event Expiration Times table in Iotellect Server Global Configuration (See Event History section).

  • The Event is queued for dispatching. Once it reaches the head of the dispatching queue, every registered listener receives a notification.

Event Dispatching

The last step of the event lifecycle is dispatching. At this stage, every subscriber processes the event instance.

While all other stages of event processing occur in the thread that generated the event, event dispatching is performed in a separate thread called Event Dispatcher. The original thread only adds events to the Event Queue of the dispatcher.

Using a queue and a separate event processing thread means that listeners may access the event later than it actually occurred. Depending on the server load factor, this delay can reach hundreds of milliseconds or even seconds if the event dispatcher's queue is large.

If the server is experiencing poor performance, it's important to diagnose the length of the event dispatcher's queue. The length of Iotellect Server's primary event queue is shown in the Event Queue Length field of the Server Status table.

Most events are handled directly by the Event Dispatcher thread, one after another, since handling them concurrently may change their processing order and cause errors if events are processed out of their correct order.

However, some events may be handled concurrently, especially if they occur in different contexts. Such events are not dispatched by the primary Event Dispatcher. Instead, they are moved to per-context Event Dispatchers and added to per-context event queues. The number of events in each per-context event queue can be determined by browsing the Event Queue Details table available via the View Server Information action of the Root context.

Was this page helpful?