Overview of the Event Management Service

General Model

An individual data entity corresponding to some information communicated from the managed environment to the management applications is known as an "event". The EMS described in this document defines the mechanisms necessary to generate and process events, thus enabling systems management applications to respond appropriately to changes in the availability and/or reliability of computing resources in the managed environment.

Today's commercial computing environments are characterized by both their distributed and heterogeneous natures. Typical environments are comprised of networks of a wide variety computer hardware and software produced by many different vendors, cooperating in some fashion to perform mission critical functions on behalf of end-users. As a result, systems management applications are required to manage a wide range of computing resources, and thus need to consume events produced by applications developed by several different vendors.

In order to enable the development of management applications that communicate and process the event information within a heterogeneous, distributed computing environment, the EMS API must be standardized. Developers of system resource monitoring services require a standard API for reporting the occurrence of events that must be processed by management applications, and management applications require a standard API for the consumption of events that may be generated by a wide variety of resource monitoring services.

This document describes both a general model for an EMS architecture, and a set of APIs tailored to mapping the general model to an X/Open compliant environment. While it would be ideal to have a single implementation that is appropriate for all computing environments, in reality different computing environments employ vastly different distribution mechanisms, and a single implementation is simply not feasible.

Part 2 of this specification describes the mapping of the EMS API to several implementations. This is meant to be a sampling of implementations. By agreeing upon the implementations for various spaces, for example, CORBA event service, implementors of event services and gateways will be able to create interoperable products.

The EMS provides reliable, in sequence, asynchronous notification of events. It is implemented as an intermediary layer between management applications and managed objects.

An event is a partially opaque object emanating from a managed object. The information (object) is partially opaque in so far as there is a standard header and an encoded data stream. The standard header provides the minimal amount of information that an EMS must be capable of filtering for any management application. The standard header also provides the minimum amount of information that an EMS must be capable of filtering for a managed object.

The EMS specification does not prescribe the mechanism used to locate Event Service instances either from a management application or managed object perspective. These relate to the given environment, for example, DCE.

The EMS specification does not address mechanisms for activating (or otherwise controlling) managed objects. These mechanisms may be incorporated into management applications.

EMS implementations operate within the security policy of the given environment. They do not implement a distinct security framework.

Model

At first glance, the core of the Event Service looks very similar to a COSSES Event Channel. There are, however, some notable differences:

• The EMS involves two or more channels, centralizing the functionality associated with reliable delivery.

• The Event Channel includes filtering mechanisms. The interface to suppliers ensures that a supplier can only insert events for which they are authorized. The [consumer-side] filter performs two major functions. First, it delineates the events in which the consumer is interested, both in terms of the event type, per se, and in terms of the criteria receiving a given event. Second, it provides a security mechanism, where the consumer can only receive events for which they are authorized.

• The event repository is designed to hold events awaiting delivery to consumers. This is used in conjunction with the filter repository and the consumer/supplier repository. The event repository must be a persistent store for reliable event delivery. It is not a permanent log. A consumer may act as a local logging facility; or, a consumer may act as a proxy for a centralized logging facility. In any case, utilizing a consumer for logging simplifies the implementation, configuration, and administration of the Event Service.

• The filter repository must be a persistent store. It contains filters registered by consumers. These are analogous to the where clause in the select statement for SQL and ODMG queries. In subsequent bindings, consumers specify a set of filters to be used as criteria for event selection. The elements of the set are anded. Hence, an event will be sent to the consumer only when it passes all of the criteria in the set.

• The consumer/supplier registry contains state information about active consumers and suppliers.

• Once events are collected for a consumer, they will persist across consumer connections, within the space restrictions set for the given XEMS instance. Should the value be exceeded, then events may be lost. The consumer may disconnect without losing events. In fact, events will continue to be gathered for the consumer. When the consumer reconnects, the events will be sent to the consumer.

• The schema repository contains information for typed events.

• The event services manager is responsible for orchestrating the activities of the Event Service.

The security context is derived from the normal means, for example, set during logon or altered via system calls (setuid, setgid, etc.). Consumers, like the EMS, are both clients and servers. As a result authentication and authorization are performed for both the registration and the event flow. The difference between the Consumer and the EMS is that the Consumer does not perform the multi-level check on the contents of the event container.

The remaining sections of this chapter describe how the event services described in this specification would typically be configured, and how developers of software components that produce and/or consume events would integrate with this service.

The "Example" section (see Examples ) illustrates aspects of the EMS through the deployment and use of an intelligent agent.

Conceptual Flow

• configuration

• authorization

• registration

• connection

• delivery

• maintenance.

Configuration of an EMS

Configuration of a Supplier

Authorization of a Consumer

Establishing Filters

Interfaces are provided manipulating, querying, and administering filters. Consumers are not required to use filters. The effect of not using a filter group is the reception of all events consumer is authorized to receive.

Supplier Connections

The EMS applies an authorization filter to the supplier. A supplier may only insert event types for which it is registered. A supplier may be permitted to insert any event type registered in the EMS. This permits generic suppliers, for example, gateways among EMS instances.

Consumer Connections

The normal sequence of operations by a consumer are:

• Use ems_consumer_start() to establish the consumer session with the EMS. This will establish the principal to receive events, the mechanism for event delivery, and the quality of the delivery.

• Query the EMS to determine what event types are available to the consumer. Based upon the selections made from the query, form filter expressions. Each filter expression provides threshold criteria for an event. Combine the filter expressions into a list.

• Use ems_filter_add() to add the list to the filter repository.

• Use ems_add_filter_to_group() to create a consumer filter group. A consumer has a single active filter group at any moment. A filter group may be queried, manipulated, and deleted.

• Use ems_push_consumer_register() to associate a filter group with an EMS instance, indicating that the latter is to send events meeting the filter criteria. This method is invoked once for every EMS instance and filter group of interest.

• Registration and/or filter group manipulation may be inter-twined to establish unique event filtering criteria at each EMS instance.

• An ems_consumer_unregister() invocation should be made for each ems_consumer_register() call. This quiesces event notification for a given EMS instance and filter group.

• Use ems_consumer_stop() to destroy the consumer session with the EMS.

Administration

• Updating the consumer/supplier registry to add or remove consumers or suppliers.

• The consumer/supplier registry may be updated to reflect new event types and schemas.

• The filter repository may become cluttered with forgotten filter lists. Or the filter lists for a consumer are to be deleted as a precursor to deleting the consumer from the registry.

• The event repository may have forgotten events. Where a consumer had registered for a set of events on behalf of a principal, but the events could not be delivered to the principal. This should be an anomaly. If events are requested, there is normally a more than casual interest in their reception.

Architecture

A number of components may be gleaned from the general model. They are:

• the event persistent cache

• the consumer/supplier registry

• the filter repository

• the event channel.

Event Services API Overview

• the Registration interface

• the Event Type interface

• the Supplier Interface

• the Filter Interface

• the Consumer Interface

• the Management Interface.

The Registration interface allows registration with EMS for applications that are not suppliers or consumers. The Event Type interface provides support for manipulating the Event Type Database. Event filters can be created using the Event Filter Interface. The Supplier interface allows suppliers to both register and send events to the EMS. The Consumer interface provides consumer setup routines and consumer registration routines. The EMS Management Interface allows management applications to administer the EMS databases, as well as the event service itself.

EMS Registration

An event service handle is required to perform any operation with the event service. These operations can be event type operations, event filter operations or event management service operations. The following routines allow EMS clients to register with EMS:

ems_register

Register with the Event Service.

ems_unregister

Unregister with the Event Service.

Another type of registration requires consumers and suppliers to register with the event service to tell the event service that they are consumers or suppliers as well as what type of consumer or supplier they are. These routines are described in the supplier and consumer sections.

Events

Event Header

• the event identifier

• the origin of the event

• the severity of the event

• the time when the event was generated

• the time when the event was delivered

• the priority of the event.

Event Data

Schemas

The EMS Event Type Interface

EMS keeps a database of event types which consists of event type schemas. Routines are provided to manipulate the event types in the event type database.

The following routines summarize the EMS Event Type Interface:

ems_event_type_add

Add a new event type schema to the Event Type Database.

ems_event_type_delete

Delete an event type schema from the Event Type Database.

ems_event_type_get

Get an event type schema from the Event Type Database.

ems_event_type_get_list

Get a list of event type schemas from the Event Type Database

ems_event_type_free_list

Free the list of event type schemas.

Filters

The EMS API supports the second stage filtering, and provides routines to manipulate the EMS Event Filter database.

The following routines summarize the EMS Event Filter Interface:

ems_filter_add()

Add a filter to the Event Filter Data base.

ems_filter_append()

Append filter expressions to the Event Filter Database.

ems_filter_get()

Get the contents of an event filter.

ems_filter_free()

Free the storage used by an event filter after a get.

ems_filter_delete()

Delete a filter from the Event Filter Database.

ems_filter_get_namelist()

Get a list of the names of all filters in the Event Filter Database.

ems_filter_free_namelist()

Free a list of filter names.

ems_filter_get_list()

Get a list of all the filters in the Event Filter Database.

ems_filter_free_list()

Free the list of filters.

Event Channel

A channel pair provides a means of decoupling consumers and suppliers. In addition, it provides a mechanism for fan-in and fan-out of events.

Consumers

The EMS maintains a consumer database to keep track of all registered consumers. Registering and unregistering with the EMS adds and deletes consumers to and from the database.

Two types of consumers, to correspond with the OMG Event Service Model, are supported, a push consumer and a pull consumer. A consumer would use the appropriate registration API to designate which type of consumer is desired

The following routines summarize the EMS Consumer Interface:

ems_consumer_start()

Called to start an event consumer.

ems_consumer_stop()

Called to stop an event consumer.

ems_push_consumer_register()

Register a push consumer.

ems_pull_consumer_register

Register a pull consumer with the Event Service.

ems_consumer_unregister()

Unregister a consumer with EMS.

ems_add_filter_to_group()

Add a filter name to a consumers event filter group.

ems_delete_filter_from_group()

Delete a filter name from a consumers event filter group.

ems_get_filter_group()

Get the list of filter names that comprise a consumers event filter group.

ems_consumer_get_registration()

Retrieve consumer registration information associated with a consumer handle.

ems_consumer_pull()

Used by pull consumers to get an event from the event management service.

ems_consumer_try_pull()

Used by pull consumers to get an event from the event management service, but not block waiting.

Suppliers

The following routines allows suppliers to send events to the EMS:

ems_supplier_send()

Send an event to EMS.

ems_supplier_register_handler()

Register a hint callback for the supplier. This requires the supplier to be both a client and a server.

ems_push_supplier_register()

Register a push supplier with the EMS.

ems_pull_supplier_register()

Register a pull supplier with the EMS.

ems_supplier_unregister()

Unregister a supplier with the EMS.

Management

The following routines summarize the EMS Management Interface:

ems_mgmt_list_ems()

List all hosts running the event service.

ems_mgmt_free_ems()

Free the host list.

ems_mgmt_list_attributes()

Lists attributes for a specific EMS.

ems_mgmt_free_attributes()

Free a list of ems attributes.

ems_mgmt_list_consumers()

List consumers registered with EMS.

ems_mgmt_free_consumers()

Free a consumer list.

ems_mgmt_secedit

Alter the permissions of a subject with regard to a security object.

ems_mgmt_secsubjadd

Add a subject to the EMS. The subject may act as a consumer or a supplier or both, based on the read/write permissions given on the call.

ems_mgmt_secsubjdelete

Remove a subject from the EMS.

ems_mgmt_secsubjget

Given a principal, return the EMS defined subject.

ems_mgmt_delete_filter_from_group()

Delete a filter name from a consumers filter group.

ems_mgmt_add_filter_to_group()

Add a filter name to a consumers filter group.

ems_mgmt_get_filter_group()

Get the list of names in a consumers filter group.

ems_mgmt_list_suppliers()

List suppliers registered with EMS.

ems_mgmt_free_suppliers()

Free a supplier list.

ems_mgmt_delete_supplier()

Delete a supplier from the Supplier Database.

ems_mgmt_get_undelivered_events()

Retrieve a list of events that have not been delivered to interested consumers.

ems_mgmt_free_undelivered_events()

Free the undelivered events in the list for interested consumers.

ems_mgmt_delete_undelivered_event()

Delete an undelivered event from the EMS Event Log.

ems_mgmt_forward()

Establish the forwarding of events described in a filter group from a given EMS to another EMS.

Performance

1. Giving timely warning of impending problems (for example, file capacity thresholds).

2. Notifying system administrators of failing processes and system components.

3. Quickly identifying root causes to problems in increasingly complex systems.

4. Automatically fixing problems before service levels are degraded.

5. Integrating application-specific event mechanisms so system correlation can be done at a higher level (for example, network outages are the root cause of many application errors; and the administrator needs his attention drawn to the root cause).

Key attributes of the EMS are:

• Lightweight - minimal network/system load
  A key requirement is that the event service have good performance characteristics, and that it not degrade performance of the network. This service must be efficient enough for real-time performance monitoring of system level activity.

• Extensible API
  The ability to define and extend events and event contents.

• Interoperable across the network
  This attribute addresses the ability event management system products from different vendors to interoperate without a priori knowledge of the specific vendor's offering.

• Robust
  Defined as the reliable delivery of events.

Reliability

• no loss of events

• self-monitoring

• stable processes.

No Loss of Events

Self-monitoring

Stable Processes

Security

The EMS may use an external security mechanism to control the consumer's or supplier's ability to register (bind) with an EMS. Given a security principal, the EMS may recognize permissions for specific objects. For example, a supplier may only be permitted to insert a specific event type, or a consumer may only be permitted to view certain event types. If multi-level access is not available, then an EMS implementation may be configured such that all users of the specific EMS have the same permission sets for all objects. Expanding upon this, a set of EMS instances may be configured for a given node, where each instance supports a specific set of users.

The EMS will operate within the security framework of the host environment. It is paramount that an implementation work within the host security mechanism. Security policies can be quite complex. The use role-based security schemes compounds the situation. For EMS implementations to have wide acceptance, they cannot insist upon using private security mechanisms.

The manifestation of a security policy is transparent to consumers and suppliers. The use of the security contexts of the consumers and suppliers, assists interoperability and usability. The sole adapter to be used for an EMS may be the authorization implementation for the vendor's abstract authorization class.

The use and understanding of a security architecture does not depend on a full-understanding of the underlying object implementations and interactions of the Event Service, consumers, and suppliers. The conceptual model for the use of security with the EMS is depicted in Security Service .

1. The security context is derived from the normal means, for example, set during logon or altered via system calls (setuid, setgid, etc.).

2. Consumers, like the EMS, are both clients and servers. As a result authentication and authorization are performed for both the registration and the event flow. The difference between the Consumer and the EMS is that the Consumer does not perform the multi-level check on the contents of the event container.

1. Neither consumers nor suppliers are aware of, that is, need code to support, a security mechanism. They simply inherent the security context of their logon group.

2. The EMS requires object level security granularity, that is, multi-level security. As a result, it must perform authorization checks for consumers and suppliers.

3. The administration functions are not depicted in this view. They are deemed to be outside the scope of the EMS specification.

4. The EMS specification is written in accordance with the proposal put forth in GSSAPIEXT to the extent that the latter provides specifications for multi-level access. For example, from the perspective of a DCE-based EMS, the calls to the ACL manager to determine whether a consumer (or supplier) has permission for a given operation on a specific event type (that is, a specific object) are:

   • "rpc_binding_inq_auth_client()"
     to obtain the authentication and authorization information from the binding handle for an authenticated client. In particular, to obtain the client's privilege attribute certificate (PAC) which is used in the test call.

   • "sec_acl_bind()"
     to obtain the handle of the object in question.

   • "sec_acl_test_access_on_behalf()"
     to test access to an object on behalf of another process, mapping the type of access implied in the original RPC call to a permission mask (for example, read, write, insert, delete, etc.).

   It is not clear whether GSSAPIEXT provides this support or has left it as an implementation specific aspect of security.

Changes in a principal's security profile may affect their ability to participate as a consumer (or supplier) either during or across conversations.

Global Namespace

The namespace affects consumers and the EMS.

The namespace is transparent to suppliers and the EMS.

Security context transfers must be capable of mapping the principal and the principal's attributes, for example, PACs for DCE-based security.

The mapping transformations must be two-way, since the information flow is both from the consumer to the EMS and vice versa.

The event flow (from the EMS to a consumer) does not require multi-level security at the consumer side.

Security Objects

ems-server

controls access to the event service.

event-types

controls access to the Event Type Database.

filters

controls access to the Filter Database.

consumers

controls access to the Consumer Database.

suppliers

controls access to the suppliers Database.

The second type of security object concerns manipulation and access to objects inside of the databases. These objects are classified by category.

event-type

controls access to a given event type in the Event Type Database

filter

controls access to a given filter in the Filter Database

The remainder of this section describes what operations can be controlled on each security object.

Event Service Attributes Security Object

control

modify this security object.

read

read or get the attributes for an Event Service.

write

write or modify the attributes for an Event Service.

Event Type Database Security Object

control

modify this security object.

delete

delete an event type from the Event Type Database.

insert

insert or add an event type to the Event Type Database.

read

read or get an event type schema from the Event Type Database.

Filter Database Security Object

control

modify this security object.

delete

delete a filter from the Filter Database.

insert

insert or add a filter to the Filter Database.

read

read or get a filter or the list of filters from the Filter Database.

Consumer Database Security Object

control

modify this security object.

delete

delete a consumer from the Consumer Database.

insert

insert (by registering) a consumer in the Consumer Database.

read

read or get a list of consumers, or a specified consumer's filter group from the Consumer database.

write

modify a consumers filter group.

Supplier Database Security Object

control

modify this security object.

delete

delete a supplier from the Consumer Database.

insert

insert (by registering) a supplier in the supplier Database.

read

read or get a list of suppliers from the supplier database.

Event Type Security Objects

control

modify this security object.

delete

delete this event type from the Event Type Database.

read

read or get the event type schema for this event type from the Event Type Database.

Filter Security Objects

control

modify this security object.

delete

delete this filter from the Filter Database.

read

read or get the filter expressions for this filter from the Filter Database.

write

write or append a filter expression to this filter in the Filter Database.

Network Communications

Security context support is provided by the environment.

Data encryption support is provided by the library. In a OMG CORBA environment, for example, this would be provided by the object system.

Encryption is at the conversation level and not at the object level. This eases the administrative burden in the sense that encryption semantics can be defined at the communications layer. The EMS need not be aware of the encryption mechanism.

Internationalization

• The language of the supplier may not be that of the consumer.

• The character set of the supplier may not be available to the consumer.

• Cultural data, for example, time and date format, may be embedded within the text-based events.

Solutions to these problems (from the perspective of wrapped legacy systems) are limited. Internationalization of textual data usually leads to rewriting sections of the original application. Here is a partial list of changes:

• Many of the language issues may be solved through the use of message catalogs. Unfortunately, the catalogs must be accessible to the consumers. For message based solutions, the message number for the message skeleton is provided as a parameter. The number of insertions is another parameter. Each of the inserts, converted to an internal form (for example, a timestamp may be shipped as a time_t), is provided as a typed (any) parameter. A complimentary adapter is required at the consumer that recognizes the event type and provides the message presentation services.

• There is little that can be done for missing character sets even with the use of a message catalog. Failures may occur when the insert is a character string, for example, a file name, and the codeset for the language is not available at the consumer.

• Most cultural problems are skirted by transmitting the internal form of the data and not the presentation form. This may be used in conjunction with a message catalog or in isolation.

For suppliers built for the EMS, there are data types for all transmitted information, including constructed types for multi-byte and UCS character sets. While this does not eliminate the problems associated with unsupported character sets, it does provide reasonable semantics for failures due to this condition. Hence, sending textual data (for example, message inserts for file names) in its specific character set mapping may permit the consumer to see a message in part, even though specific inserts might not be viewable.

Interoperability

An Event Service maintains one or more repositories. The composition of these repositories is beyond the scope of this specification. The interfaces to these repositories is in the administrative domain.

Different Event Management Applications

In particular this means, that regardless of the implementation of the EMS, the event management application of choice can be used for further processing and presentation.

Different Event Protocols

• Event suppliers based on different protocols (for example, SNMP traps).

• Event consumers based on different protocols (for example, OMG based event service implementation).

As stated at the beginning of this section, gateways are used to provide interoperability across event service implementations. The EMS APIs are compatible at the source level. Suppliers and consumers built for different EMS implementations may be connected to a given EMS via adapters. The idea is to implement a protocol independent interoperability layer connecting the different worlds. See Managed Node .

The translator modules establish access to the different event worlds by translating the particular event format (for example, SNMP trap) into the common standardized format, and vice versa.

The protocol independent layer establishes the access to the event service, utilizing the standardized event creation and registration APIs. With that layer it's possible to centrally manage events from different protocols, and to communicate between different event service implementations (DCE vs. OMG).

Interoperability of EMS Implementations

Interoperability: Protocol Independent Channel is undoubtedly a simplification of a complex problem that plagues the industry. But it provides a logical view of what is needed to solve interoperability. In general, some component is needed to translate events produced by a supplier using one transport to events that can be consumed by another transport event consumer, and vice versa. Such a component is purely logical, and may in fact be implemented using one to several processes.

As mentioned in the previous paragraph, the protocol independent event channel depicted in Interoperability: Protocol Independent Channel is purely logical, and several vastly different implementations are imaginable. Probably the simplest, although not necessarily the most efficient, implementation would be to start with an environment that supports both implementations. Then, a component could be implemented that is both a consumer and a supplier. This scenario is depicted in Interoperability: Dual Environment Channels .

Examples

The process flow is then:

1. connect with the agent factory

2. set up the transfer of initialization information

3. transfer the agent and applettes

4. set up the supplier with the EMS

5. set up the consumer with the EMS

6. start the supplier

7. send completion status to the consumer with a reference to the EMS conversation.

Initial Connection Flows

1. Connect to the agent manager factory on the destination node. The factory needs to know the event recipient, quality of service, and the agent. The factory returns an object reference for the agent.

2. The agent may consist of several applettes. The agent and each applette is shipped to the factory. The factory sets up the agent environment, insuring that it can be restarted in the event of a failure.

Setup the Supplier with the EMS

1. Use ems_register() to bind to the EMS.

2. Use ems_event_type_add() to add the event type, the identity of the agent in this case.

3. Use ems_mgmt_add_supplier() to add the agent.

4. Use ems_mgmt_add_supplier_of_event() to connect the agent to the event type as a supplier.

5. Use ems_unregister() to disconnect from the EMS.

Setup the Consumer with the EMS

1. Use ems_register() to bind to the EMS.

2. Use ems_mgmt_add_consumer_of_event() to permit the consumer to receive events of the given type. This method should not fail, because the factory used the EMS to ensure that the consumer could utilize this facility.

3. Use ems_filter_add() to indicate that the consumer is to receive all events from the agent.

4. Use ems_unregister() to disconnect from the EMS.

Start the Supplier

1. The factory for the intelligent agent has placed the agent and the applettes in a directory. In addition to the executables, the factory has placed state and context information in the directory.

2. The factory activates the agent in the context of the directory it previously built. The agent executes with the security credentials and permissions of the consumer.

The Supplier

1. The agent executes with the directory created by the factory as its current working directory.

2. The agent does not know the difference between the initial invocation and an invocation after a failure, for example, power outage.

3. Use ems_push_supplier_register() to bind to the EMS.

4. For each event to be sent, use ems_supplier_send().

5. Before terminating the agent, use ems_supplier_unregister() to remove the conversation with the EMS.

6. Set the conversation state to completed. The conversation manager will remove the files and directory information.

7. Conversation manager remove supplier.

Conversation Manager Remove Supplier

1. Use ems_register() to connect to the EMS.

2. Use ems_mgmt_delete_supplier_of_event() to disassociate the agent from the event type.

3. Use ems_mgmt_delete_supplier() to remove the agent from the EMS.

4. Use ems_unregister() to disconnect from the EMS.

Conversation Manager Remove Conversation

1. locate the directory for the agent

2. conversation manager remove supplier

3. conversation manager remove consumer

4. conversation manager remove event type

5. remove the agent directory and its contents.

Conversation Manager Remove Consumer

Use ems_mgmt_delete_consumer_of_event() to remove the association between the consumer and the event type. This has the side-affect of removing all undelivered events of this type for this consumer.

Conversation Manager Remove Event Type

Use ems_event_type_delete() to remove the event type. ,HU "The Consumer" This section chronicles the flow of the consumer, when the event recipient is the consumer.

1. Initial connection setup.

2. Use ems_consumer_start() to connect or reconnect to the EMS. The library determines whether it is an initial connection or a reconnect based on the input argument. The library returns the object reference representing the conversation.

3. Use ems_consumer_handler_register() to present a method to receive event notifications to the EMS library.

4. Use ems_push_consumer_register() to set the EMS library notification mode.

5. Use ems_consumer_stop() to disconnect the conversation. The conversation is effectively terminated by interrupting delivery of events to the consumer.