RTI Connext Java API
Version 5.0.0
|
Contains the com.rti.dds.subscription.Subscriber, com.rti.dds.subscription.DataReader, com.rti.dds.subscription.ReadCondition, and com.rti.dds.subscription.QueryCondition classes, as well as the com.rti.dds.subscription.SubscriberListener and com.rti.dds.subscription.DataReaderListener interfaces, and more generally, all that is needed on the subscription side. More...
Modules | |
Subscribers | |
com.rti.dds.subscription.Subscriber entity and associated elements | |
DataReaders | |
com.rti.dds.subscription.DataReader entity and associated elements | |
Data Samples | |
com.rti.dds.subscription.SampleInfo, com.rti.dds.subscription.SampleStateKind, com.rti.dds.subscription.ViewStateKind, com.rti.dds.subscription.InstanceStateKind and associated elements | |
Contains the com.rti.dds.subscription.Subscriber, com.rti.dds.subscription.DataReader, com.rti.dds.subscription.ReadCondition, and com.rti.dds.subscription.QueryCondition classes, as well as the com.rti.dds.subscription.SubscriberListener and com.rti.dds.subscription.DataReaderListener interfaces, and more generally, all that is needed on the subscription side.
Data is made available to the application by the following operations on com.rti.dds.subscription.DataReader objects: com.rti.ndds.example.FooDataReader.read, com.rti.ndds.example.FooDataReader.read_w_condition, com.rti.ndds.example.FooDataReader.take, com.rti.ndds.example.FooDataReader.take_w_condition, and the other variants of read() and take().
The general semantics of the read()
operation is that the application only gets access to the corresponding data (i.e. a precise instance value); the data remains the responsibility of RTI Connext and can be read again.
The semantics of the take()
operations is that the application takes full responsibility for the data; that data will no longer be available locally to RTI Connext. Consequently, it is possible to access the same information multiple times only if all previous accesses were read() operations, not take().
Each of these operations returns a collection of Data
values and associated com.rti.dds.subscription.SampleInfo objects. Each data value represents an atom of data information (i.e., a value for one instance). This collection may contain samples related to the same or different instances (identified by the key). Multiple samples can refer to the same instance if the settings of the HISTORY QoS allow for it.
To return the memory back to the middleware, every read() or take() that retrieves a sequence of samples must be followed with a call to com.rti.ndds.example.FooDataReader.return_loan.
The application accesses data by means of the operations read
or take
on the com.rti.dds.subscription.DataReader. These operations return an ordered collection of DataSamples
consisting of a com.rti.dds.subscription.SampleInfo part and a Data
part.
The way RTI Connext builds the collection depends on QoS policies set on the com.rti.dds.subscription.DataReader and com.rti.dds.subscription.Subscriber, as well as the source_timestamp
of the samples, and the parameters passed to the read()
/ take()
operations, namely:
The read()
and take()
operations are non-blocking and just deliver what is currently available that matches the specified states.
The read_w_condition()
and take_w_condition()
operations take a com.rti.dds.subscription.ReadCondition object as a parameter instead of sample, view or instance states. The behaviour is that the samples returned will only be those for which the condition is com.rti.dds.infrastructure.true. These operations, in conjunction with com.rti.dds.subscription.ReadCondition objects and a com.rti.dds.infrastructure.WaitSet, allow performing waiting reads.
Once the data samples are available to the data readers, they can be read or taken by the application. The basic rule is that the application may do this in any order it wishes. This approach is very flexible and allows the application ultimate control.
To access data coherently, or in order, the PRESENTATION QoS must be set properly.