Product: OpenFusion Notification Service

Version: ALL

Description:

Which Quality of Service properties are available with the Notification Service?

Resolution:

Configurable QoS properties are an important feature of the Notification Service. An implementation of the Notification Service is not required to support all the different QoS properties described in the specification, but an implementation that does will cover a wide range of application requirements.

The following categories of QoS properties are available:

A. RELIABILITY
The Notification Service supports two aspects of reliability:

Event Reliability
Events can be delivered according to a best effort policy where no guarantees about delivery are made. Alternatively, guaranteed delivery is supported where events are be kept in a persistent store until they have been successfully delivered to all connected consumers.

Connection Reliability
Connections to event suppliers and consumers can have a reliability of best effort when the Notification Service regards connections as transient and failure to deliver or receive an event will (perhaps after a few attempts to re-connect) result in disconnection. Alternatively, connections can be made persistent, when a supplier or consumer will not be disconnected until the target object no longer exists.

B. QUEUE MANAGEMENT
The Notification Service supports a number of QoS properties related to queue management. Queue management can be based either on the current number of events in a queue or the current memory usage of the machine on which the Notification Service is running.

Maximum queue size
Rather than just leaving the problem of internal buffer overflow as an implementation detail, the Notification Service supports configuration of the maximum number of events that will be stored on behalf of consumers.

Delivery Policy
The delivery policy defines the order in which events are delivered to event consumers. The Notification Service supports a number of policies including FIFO, priority, and time out.

Discard Policy
If an event queue is exhausted, discard policies such as FIFO, LIFO, priority and time out are supported. Also, the Notification Service can be configured to discard new events.

MaxUnacknowledged
This affects DeliveryQueues. MaxUnacknowledged is the number of unacknowledged events after which event delivery to an attached listener should halt pending the next acknowledgment.

MaxMemoryUsage
This setting is used on Event Channels. MaxMemoryUsage is similar in purpose to the property MaxQueueLength, except the size of memory is controlled rather than the number of events. MaxMemoryUsage takes a value of type ulonglong which represents the number of bytes after which attempts should be made to limit memory usage using the current usage policy, which in turn is controlled using the property MaxMemoryUsagePolicy.

MaxMemoryUsagePolicy
This setting is used on Event Channels. MaxMemoryUsagePolicy is the policy by which memory usage is controlled when MaxMemoryUsage is exceeded. It can take one of three values:
- PurgeEvents - if this value is set, then whenever an event is received that takes memory usage above MaxMemoryUsage then that event will be added to the internal queue of the appropriate event channel as normal. Then, in a manner that mirrors discard behavior, the event at the back of the queue will have its data purged from memory. If the event has best-effort delivery semantics then it is effectively discarded and all its used memory should be available for recovery by the garbage collector. However, in the case of a persistent event a placeholder will remain in memory so that the data can be reloaded from persistent store when required. Hence, in the case of a persistent event not all of the used memory is freed so total memory usage will continue to increase. The rate of increase will be greatly reduced however, making this an appropriate policy for dealing with bursts of event delivery.
- DiscardEvents - if this value is set, whenever an event is received that takes memory usage above MaxMemoryUsage threshold, an event is discarded according to the current discard policy.
- RejectEvents - if this value is set then whenever an event is received that takes memory usage above MaxMemoryUsage threshold, an org.omg.CORBA.IMP_LIMIT exception is thrown.

C. EVENT MANAGEMENT
A number of QoS properties related to event management can be set. As mentioned in the previous section, these QoS properties should be set in the variable header of a structured event:

Start time
An absolute start time can be set for each event. An event will not be delivered to any consumer connected to an event channel until the start timer expires.

Time out
A relative time out value for an event can be specified. Alternatively, an absolute stop time can be used. Events will be removed from any delivery queue when the stop timer expires. When events are delivered according to the time out policy, events with the shortest relative time out value will be delivered first.

Priority
The priority of events can be specified. This QoS is used for queues with a priority delivery or discard policy.

D. BATCH HANDLING
In relation to sequence type consumers where events are delivered in batches, a few additional QoS properties are provided:

Maximum batch size
The maximum number of events that a sequence type consumer wishes to receive at a time.

Pacing interval
The maximum time a sequence type consumer will wait for events to be collected. If fewer events than the batch size are available when the pacing timer expires, the Notification Service just delivers whatever events are available. As with filters, the QoS properties can be applied in the context of logical groups.

As an example, the initial QoS properties of an event channel object will apply to all the administration objects that are subsequently created by the channel. However, fine-grained QoS is also supported, e.g. different delivery or discard policies can be specified for individual proxies.
Notification Service vendors can have additional QoS properties as value added features of an implementation. An important property of the Notification Service is that this can be done without introducing incompatibilities. The QoS interfaces have operations for negotiating and obtaining the QoS settings supported by a particular implementation.

E. BACKWARDS COMPATIBILITY
Two QoS properties have been added to enable clients to behave as specified in earlier versions of the OMG Notification Service Specification:

DisconnectCallback
This affects all proxies. If it is set to true (the default) then when a proxy's disconnect method is called, then the disconnect method on its connected client will also be called. If it is set to false, then a proxy's connected client will not have its disconnect operation invoked when that of the proxy is invoked.

AlwaysPull
This affects EventChannels. If it is set to true (the default), then events will be pulled from connected pull suppliers regardless of whether any consumers are currently connected. If it is set to false then no events are pulled unless there is at least one push consumer attached, or at least one pull consumer that is currently attempting to pull an event.