Event Service Overview

(Initially written by - Nathan Dykman, Kostadin Damevski, Ayla Khan, Steven Parker - 3/28/2007,
modifications by Kostadin Damevski on several occasions since)

 

1 Introduction

This document contains a proposal to add event processing capabilities to the CCA specification. In this, our goal to provide a simple mechanism for event distribution that meets the needs of the HPC community, while adhering as much as possible to other commonly used frameworks and taking full advantage of their experience and ideas.

The proposed event service specification is amenable to different implementation that may differ in the semantics that they provide. The basic capabilities of the event service that should be provided by all implementations are discussed in Section 2, while possible extensions to provide slightly different capabilities are mentioned in Section 3. Some implementation issues are mentioned in Section 4.

2 Basic Capabilities of the Event Service Specification

2.1 Event Service

We propose a “publish-subscribe” model, similar to the one used in the Message Oriented Middleware (MOM) domain. At the heart of most MOM is a system that provides a hierarchy of topics on which events can be sent (publishing to a topic) and or received (subscribing to a topic). 

At the core of the event system is the event service. This service is responsible for organizing the namespace of topics, setting and enforcing event policies, and maintaining the resources needed for event distribution. This service is based on two separate interfaces (PublisherEventService and SubscriberEventService) to differentiate the methods that ought to be called by an event publisher from those called by a subscriber. The event service guarantees delivery of an event to all components who are subscribers to this event at the time of delivery (when the event service's processEvents method is executed)

Processing events need to be handled either asynchronously or synchronously. For asynchronous event handling, a process or threads needs to be available that will take care of event processing. In the synchronous case, a thread will yield in order to allow events to be processed. Threads are processed using the processEvents method, which flushes all events queued in the event service to the subscribers.

2.2 Topic

Topic hierarchy organization is analogous to a file system structure. This hierarchy, which allows topics so be grouped together, allows one to subscribe to topic groups as well as individual topics.

Here is are two sample topics:

functions.signals.iteration
functions.signals.currentStepDone.time

From this, we can tell that there is a topic group called functions and in that group, we have a sub-group of topics called signals. In this signals sub-group, there is a topic called iteration and another sub-group of topics called currentStepDone. Finally, in currentStepDone sub-group there is a topic called time. We can simply subscribe to any of these two topics by using their full name (e.g. functions.signals.currentStepDone.time) . However, to listen for all events on every topic in the functions.signals group, we can use a wildcard syntax. Namely, we use a “*” token to match either of the sample topics given above:

functions.signals.*

To match only one dot-delimited segment we use  a “?” wildcard token. This would select only the functions.signals.iteration topic:

functions.signals.?

Even more flexibly, we subscribe to any group which has a subgroup called signals as follows:

*.signals.*

It is important to note that topics are just channels in which events are sent. The topic does not bind what type of event can or can’t be sent on it. In this sense, the topics are merely named channels for events to be distributed, nothing more.

2.3 Subscription

When we subscribe to one or more topics, we receive a subscription handle. This handle is used to manage the the subscription (e.g. register listener object(s)).

2.4 Event

CCA events have the following information:

• Message header: A message header should not be empty. It should contain basic metadata, which at the very least is the ComponentID of the publisher of the event.
  

• Message body: Stores the event payload.
  

The event header and body are represented by a CCA Typemap, which is stores key-value pairs of different datatypes (e.g. string, double, etc.).

2.5 Reserved Topics

The top level topic group cca is reserved for standard CCA events, such as those generated by the framework.

3 Possible Extensions to the Basic Event System

We encourage a number of implementations of the CCA event service in order to meet the needs of various groups of users and various platforms. However, in order to reduce the confusion that may be experienced by users that encounter more than one event service implementation, we demand the each implementation to be well documented. This section defines a number of directions in extending the basic event service capability.

3.1 Event Service Extensions

a) Constrain Resources by limiting the storage for events (perhaps by using some sort of a circular buffer)
This would prevent bloat in the resources the event service consumes, especially when the processEvents method is called very infrequently
caveat: May lead to dropped events

b) Event Persistence - storing events for a certain period of time (perhaps by using a time to live mechanism for each event)
In our opinion, this is possible to do in two ways:

1. smarts in the event services - the event service maintains the knowledge of what events need to be delivered to which listeners
   caveat: may not scale well
2. smarts in the event listener - ssome listeners may receive the same event from the event service more than once. listener components need to be prepared for this possibility.
   

c) Local Scale: This means that the events are only seen on a per component basis, only on a per-framework basis.

d) Filtered Components: This allows for filters to be run on the events when they are sent or received. The filtering runs on the event-service resource, not on the resource that is sending or receiving the events.

3.2 Extensions to Topic Management

One possible model is to only allow components with the proper permissions to programmatically create topics. Another possibility is to tracks the resources associated with a CCA task or computation, and give each of these tasks their own set of resources (including queues, etc.). These tools will allow management of the topic space, logging and monitoring of the event system and management of topic queues.

4 Issues in Implementation

At the heart of the implementation is the process events call on the event service. This is when all event processing occurs. In a system that doesn’t allow for a dedicated resource to be scheduled to process events (a dedicated thread, component in a given framework, etc.) then the computational resources must yield explicitly by calling process events on the event service.
An efficient implementation of an event service is not easy. However, even simple implementations can be efficient if the following guidelines are followed:

• Do as little computation in event receivers as possible. The event receiver should note the appropriate state, store it, and return. Complex logic or other processing should be done elsewhere.
• In systems with multiple threads, the task of event processing can be parallelized by using a work queue model. For each event that needs to be processed, it can be handed to a thread in the pool. When the processing is finished, the thread returns to the pool.
• If a dedicated set of threads can be used for event processing, then each thread can maintain its own queue of events. When each event is sent, it is delegated to each thread in a round-robin or other scheduling mechanism. A more advanced mechanism could dynamically size the thread pool based on demand.