4.2.7. RTI Infrastructure Services

4.2.7.1. XML Compatibility

Infrastructure Services products may fail to load an XML file from releases prior to 6.1.0 if the <group_data>, <user_data>, or <topic_data> tag is specified in the file using the the old format, in which the content is provided as a set of comma-separated decimal or hexadecimal element values. See Section 4.1.5.2 for more information.

4.2.7.2. RTI Routing Service

4.2.7.2.1. Periodic event now configurable individually per Route

A periodic event can now be individually enabled and configured for each Route as follows:

<route>
   <periodic_action>
         <sec>0</sec>
         <nanosec>400000000</nanosec>
   </periodic_action>
</route>

This setting overrides the one specified in the <session>. The <periodic_action> in the <session> tag is still supported and allows you to define a default value for all contained routes.

The new functionality has also been applied to the Processor API, so the Route::period() operation only affects the Route object and not the parent Session. Make sure your application is updated accordingly if these changes affect it.

4.2.7.2.2. Register type and content filter tags changed

The tags <registered_type> and <content_filter> have been modified to match the DDS-XML specification.

<registered_type> (in the <connection> and <participant> tags) has been renamed to <register_type>, and there are changes to its possible attributes and elements.

The possible attributes and elements for <content_filter> (in <input> (in <topic_route>) and in <dds_input> (in <route>)) have changed. They have changed from a <parameter> list in <content_filter> to <expression_parameters> with an <element> list in <content_filter>.

The previous values are still allowed, but a warning will be displayed. Future versions will fail if the old tags are still present.

Note

The <participant_qos> tag did not change to <domain_participant_qos> for Routing Service in release 6.1.0.

4.2.7.3. RTI Recording Service

4.2.7.3.1. Files table extended

Previously, Recording Service used the ‘Files’ table to hold all information about the recorded user files. (‘Files’ is an internal table that Recording Service uses to replay the recorded database.) In 6.1.0, this internal table has been updated to also contain the maximum and minimum source timestamp. To not lose compatibility with 6.0.1, this internal table has been renamed ‘Files_2_0.’

Therefore, the first time that you replay a 6.0.1 database using Replay Service 6.1.0, the replay will need some time to create the ‘Files_2_0’ table and calculate the maximum and minimum source timestamp of each file. The size of the metadata file can also grow.

4.2.7.3.2. Instance History Replay

The new Instance History Replay feature requires some new tables in order to store the custom instance history index. These tables are required in order to calculate the state of the world efficiently.

The first time that you replay a 6.0.1 recorded database with this feature enabled, the Replay Service will need significant time to index the tables. Also, the size of the database will grow due to the creation of the new tables.

4.2.7.4. RTI Persistence Service

4.2.7.4.1. Incompatible Persistent Storage (Database) Format

In 6.1.0, the schema of the persistent storage files and tables created by Persistence Service to store DDS samples and instances has changed. Therefore, you cannot use the files and/or tables generated with previous releases of Persistence Service with Connext 6.1.0.

If you have this requirement, contact RTI Support at support@rti.com.