Listener Interface Reference
[Entity Support]

<<interface>> Abstract base class for all Listener interfaces. More...

Inheritance diagram for Listener:

DataWriterListener DataReaderListener TopicListener EntityHowTo.MyEntityListener DataWriterAdapter PublisherListener DataReaderAdapter SubscriberListener DomainParticipantListener TopicAdapter PublisherAdapter DomainParticipantListener PublisherAdapter SubscriberAdapter DomainParticipantListener SubscriberAdapter DomainParticipantAdapter DomainParticipantAdapter DomainParticipantAdapter DomainParticipantAdapter DomainParticipantAdapter

Detailed Description

<<interface>> Abstract base class for all Listener interfaces.

QoS Policies
Status Kinds
All the supported kinds of concrete interfaces (one per concrete type) derive from this root and add methods whose prototype depends on the concrete Listener.

Listeners provide a way for RTI Connext to asynchronously alert the application when there are relevant status changes.

Almost every application will have to implement listener interfaces.

Each dedicated listener presents a list of operations that correspond to the relevant communication status changes to which an application may respond.

The same instance may be shared among multiple entities if you so desire. Consequently, the provided parameter contains a reference to the concerned

Access to Plain Communication Status

The general mapping between the plain communication statuses (see Status Kinds) and the listeners' operations is as follows:


Hierarchical listener processing. The most specific relevant enabled listener is called.

This behavior allows the application to set a default behavior (e.g., in the listener associated with the and to set dedicated behaviors only where needed.

Access to Read Communication Status

The two statuses related to data arrival are treated slightly differently. Since they constitute the core purpose of the Data Distribution Service, there is no need to provide a default mechanism (as is done for the plain communication statuses above).

The rule is as follows. Each time the read communication status changes:

The rationale is that either the application is interested in relations among data arrivals and it must use the first option (and then get the corresponding objects by calling on the related and then get the data by calling or on the returned objects), or it wants to treat each independently and it may choose the second option (and then get the data by calling or on the related

Note that if is called, RTI Connext will not try to call However, an application can force a call to the objects that have data by calling

Operations Allowed in Listener Callbacks

The operations that are allowed in callbacks depend on the QoS policy of the to which the is attached -- or in the case of a of listener, on the QoS of the parent or For instance, the settings of a will determine which operations are allowed within the callbacks of the listeners associated with all the DataReaders created through that

Note: these restrictions do not apply to builtin topic listener callbacks.

Regardless of whether is set to true or false, the following operations are not allowed:

An attempt to call a disallowed method from within a callback will result in RETCODE_ILLEGAL_OPERATION.

If is set to false, the setting which allows more concurrency among RTI Connext threads, the following are not allowed:

An attempt to call a disallowed method from within a callback will result in RETCODE_ILLEGAL_OPERATION.

The above limitations can be lifted by setting to true on the or (or on the of the to which the listener is attached. However, the application will pay the cost of reduced concurrency between the affected publishers and subscribers.

See also:

Status Kinds,

RTI Connext Java API Version 4.5f Copyright © 17 Mar 2012 Real-Time Innovations, Inc