8. Release Notes

8.1. Supported Platforms

RTI® Recording Service is supported on the platforms listed in Table 8.1.

It can also be deployed as a C++ library linked into your application. This is true for all platforms in Table 8.1.

Table 8.1 Supported Platforms in 6.0.1
Platform Operating System
Linux All Linux platforms in the RTI Connext DDS Core Libraries Release Notes with the same version number, except NI Linux 3 on Arm® v7 and Wind River® Linux 7 on x64.
macOS® All macOS platforms in the RTI Connext DDS Core Libraries Release Notes with the same version number.
QNX® All QNX Neutrino® 7.0 platforms in the RTI Connext DDS Core Libraries Release Notes with the same version number.
Windows® All Windows® platforms in the RTI Connext DDS Core Libraries Release Notes with the same version number.

Recording Service is also supported on the platforms in Table 8.2; these are target platforms for which RTI offers custom support. If you are interested in these platforms, please contact your local RTI representative or email sales@rti.com.

Table 8.2 Custom Platforms
Platform Operating System
Linux Yocto Project 2.5 on Arm v7

8.2. Compatibility

For backward compatibility information between Recording Service 6.0.1 and previous releases, please see the Migration Guide on the RTI Community portal.

8.3. What’s New in 6.0.1

8.3.1. New platforms

Recording Service, Replay Service, and Converter now include support for these platforms:

  • macOS 10.14 (x64)
  • Ubuntu 16.04 LTS (Arm v8 x64)
  • QNX 7.0 (x64 and Arm v8 x64)
  • Red Hat® Enterprise Linux 8 (x64)
  • Windows 10 (x86, x64) with Visual Studio® 2019
  • Windows Server 2016 (x86, x64) with Visual Studio 2019
  • Yocto Project 2.5 (Arm v7) (custom target platform)

For more information on these platforms, see the RTI Connext DDS Core Libraries Platform Notes for this release.

8.3.2. Removed platforms

These platforms are no longer supported:

  • macOS 10.11
  • Windows 7
  • Windows Server 2008 R2

8.3.3. New <topic_name> tag to specify DDS topic name

In the previous version, the <topic> tag used the name attribute to refer to both its own name and the DDS topic to be recorded, replayed, or converted. This can be problematic when the topic name contains special characters that cannot be used in an XML attribute. It can also be problematic when the name uses a character or string also used by Recording Service, Replay Service, or Converter for other purposes. For example, the :: string is the separator for administration and monitoring names within the tool.

The new <topic_name> tag, which is not required but encouraged, will be used to obtain the DDS topic name if present, instead of using the <topic> tag’s name attribute. You can fall back to the previous behavior by not specifying <topic_name>, in which case the name attribute will be used instead.

8.3.4. Replay fidelity improved with large data

Replay Service’s performance has been improved when working with large data. Reading the samples to be replayed has been decoupled from the process of writing the samples to DDS. This change provides better fidelity by reducing the delay in writing.

8.3.5. Improved performance when creating legacy database stream readers

This release provides better performance when creating legacy database stream readers in Replay Service or Converter (that is, when using Replay Service or Converter with the <legacy> storage plugin).

8.3.6. Support for remotely triggered flush of user-data to disk

This release incorporates a new operation mode in Recording Service, called buffering mode. It also includes a new remote administration operation, flush.

Buffering mode allows you to start Recording Service in a listening-only mode, where the service just buffers data but doesn’t actually write it to disk automatically.

By using the new remote flush operation, you can remotely control exactly when the data is written to permanent storage. Upon receiving this remote command, the service will command all the Topics and Topic Groups to store all the buffered data.

For more information about these features, see the User’s Manual, section 3.1.4, Controlling Recording Service’s Operation Mode.

8.4. What’s Fixed in 6.0.1

8.4.1. Legacy deserialized database table couldn’t be replayed or converted if it contained compact byte sequences or arrays

Replaying or converting a legacy (version 5.3.1 or older) database stored in deserialized format failed if the database was recorded with octet/char sequences/arrays stored as blobs (that is, in compact mode). For example:

struct LargeByteSeqType {
  sequence<octet, 65530> large_byte_seq;

If the database stored large_byte_seq as a BLOB column, then Replay Service or Converter failed and complained with the following message:

exception:[DRT_DynamicType_expand_sequence_v3@3379]:Sequence length
greater than built-in max

This problem has been resolved.

[RTI Issue ID RECORD-957]

8.4.2. Segmentation fault in Replay Service or Converter if recorded topics had “::” in their names

This issue happened when a DDS topic contained :: as part of its name. Replay Service or Converter would hit a segmentation fault when trying to process that topic’s table. This issue has been resolved.

[RTI Issue ID RECORD-959]

8.4.3. Detection of termination in Converter fixed

When running Converter, it was possible that some topics weren’t converted before the application terminated. This was due to a poor termination detection schema. This problem has been resolved.

[RTI Issue ID RECORD-970]

8.4.4. QoS Topic Filters were not supported

Recording Service entities previously ignored QoS Topic Filters. This problem has been resolved. The entities listed below will obtain the QoS within the selected profile having a matching topic filter based on the actual name of the Topic they are associated with.

  • Topic (both Recording Service and Replay Service)
  • TopicGroup’s (both Recording Service and Replay Service)
  • Remote Administration Replier
  • Monitoring DataWriters

For example, consider the following QoS profile, which uses topic filters.

<qos_library name="QosLib">
    <qos_profile name="QosProfile"">
        <datawriter_qos topic_filter="MyTopic">
        <datareader_qos topic_filter="MyTopic">
        <datawriter_qos topic_filter="rti/service/admin/command_reply">
        <datareader_qos topic_filter="rti/service/admin/command_request">
        <datawriter_qos topic_filter="rti/service/monitoring/periodic">

And the following Recording Service configuration:

<recording_service name="MyRecorder">
        <writer_qos  base_name="QosLib::QosProfile" />
        <reader_qos base_name="QosLib::QosProfile" />
        <writer_qos  base_name="QosLib::QosProfile" />

               <reader_qos  base_name="QosLib::QosProfile" />

               <reader_qos  base_name="QosLib::QosProfile" />
           </topic_group >


The corresponding DDS entities below will be created with the QoS that matches the topic filter based on the topic name:

DDS Entity QoS from QosLib::QosProfile Topic filter
Topic’s DataReader reader QoS MyTopic
TopicGroup’s DataReader for topic name=MyTopic reader QoS MyTopic
TopicGroup’s DataReader for topic name=Other reader QoS NULL
Administration Replier’s DataReader reader QoS rti/service/admin/command_request
Administration Replier’s DataWriter writer QoS rti/service/admin/command_reply
Monitoring Periodic DataWriter writer QoS rti/service/monitoring/periodic
Monitoring Config and Event DataWriter writer QoS NULL

[RTI Issue ID RECORD-1008]

8.4.5. Execution directories overwritten incorrectly

Using the <execution_dir_expression> tag (under <fileset>) with the autonumeric format (for example, %auto:0-9%) did not always give the expected results. Recording Service always began writing in the first directory (0), instead of looking for the first unused directory within the specified range (0-9).

This problem has been resolved. Now Recording Service will start writing in the first available execution directory, unless the <overwrite_policy_kind> tag (under sqlite>) is set to DO_NOT_TOUCH.

[RTI Issue ID RECORD-1010]

8.4.6. Segmentation fault in Recording Service if <time_limit> didn’t have all its child properties

When using Recording Service’s <time_limit> tag, if any of the child tags were missing, the service would crash. For example, the following XML code is missing the <days> tag, which caused Recording Service to crash.


This problem has been resolved.

[RTI Issue ID RECORD-1030]

8.4.7. Possible race condition in Replay Service when looping enabled and pause/resume issued

Sending remote pause/resume commands to Replay Service may have caused a race condition if looping was enabled. When this condition occurred, Replay Service stopped sending samples because of a corruption in the internal timers. This problem has been resolved.

[RTI Issue ID RECORD-1036]

8.4.8. Possible segmentation fault when replaying or converting legacy database with compressed octet/char sequences

Replaying or converting a legacy database with a table containing a sequence of bytes (chars or octets) stored as a blob (that is, compressed mode) may have caused a segmentation fault. The error occurred when the application tried to set the value of the sequence in the Dynamic Data object. This problem has been resolved.

[RTI Issue ID RECORD-1037]

8.4.9. Missing shutdown messages

Recording Service did not show any messages when shutting down. This problem has been resolved. Now Recording Service shows the following message when it begins its shutdown process:

Stopping RTI Recording Service

Once Recording Service has stopped, it will show the next message:

RTI Recording Service stopped

[RTI Issue ID RECORD-1054]

8.4.10. XML attribute values were overwritten if element set with variable

If an XML element used a variable to specify its value, any contained attributes were incorrectly overwritten with the value of that variable.

For example, consider this XML:

<file_size_limit unit="MEGABYTES">$(MAX_SIZE)</file_size_limit>

The unit attribute was overwritten with the value of the MAX_SIZE environment variable. So if MAX_SIZE = 100, the result was:

<file_size_limit unit="100">100</file_size_limit>

This incorrect behavior applied to any XML element. This problem has been resolved.

[RTI Issue ID RECORD-1061]

8.4.11. Segmentation fault when no valid configuration file found

If Recording Service could not find a valid configuration file to load, this caused a segmentation fault. This may have occurred when:

  • The default RTI_RECORDING_SERVICE.xml file could not be found. This can happen if it has accidentally been renamed or the Recording Service executable has been moved.
  • The default user configuration USER_RECORDING_SERVICE.xml could not be found in the current working directory.
  • No other means to obtain the XML configuration were provided, such as using the -cfgFile command-line option, or specifying the configuration file or strings property if using Recording Service as a library.

This problem has been resolved. Now you will see an error message but no segmentation fault.

[RTI Issue ID RECORD-1078]

8.4.12. Possible segmentation fault when converting legacy database to CDR_AUTO format

When converting a legacy (pre-6.0.0) database to the new database format, if the exported sample format used was XCDR_AUTO, there may have been cases, depending on the types and actual samples exported, where Converter threw a segmentation fault when shutting down. This problem has been resolved.

[RTI Issue ID RECORD-1115]

8.5. Previous Releases

8.5.1. What’s New in 6.0.0

Recording Service, Replay Service, and Converter are completely new in this release. They have been entirely rewritten, with these goals in mind:

  • Improving performance
  • Simplifying configuration
  • Becoming more consistent with other infrastructure services
  • Supporting new use cases

There are a few limitations compared to the prior version:

  • Does not support Recording Console, however, RTI Admin Console provides some of the functionality.
  • Does not yet support replaying in the original partition.
  • Does not include a remote shell application, but that is provided as an example. Avoiding gaps in Replay when using time ranges

Replay Service used to extend the start timestamp to include relevant discovery data in the time range. While this allowed for the discovery of topics whose discovery events may have been out of the specified time range, it could also cause gaps when the discovery data and target data to be replayed were separated in time. To avoid these gaps, Replay Service no longer internally modifies the start timestamp defined by the user. All discovery data prior to the defined start timestamp will be discovered instantaneously.

8.5.2. What’s Fixed in 6.0.0 Pluggable storage for Converter discarded plugin properties specified in XML

When using the pluggable storage APIs with Converter, the properties passed to the plugin in the input_storage or output_storage tags (as shown below) were discarded. This problem has been resolved. Now the properties are passed to the plugin.

    <plugin plugin_name="StorageLib::StoragePlugin">


8.6. Known Issues

8.6.1. Recording Service may fail when current working directory in c:\Program Files

Recording Service will try to write to its database in the current working directory. If it does not have permissions to write there, it will fail with a confusing error:

 create_connection:!SQLite - failed to open database file; sqlite
 returned error: out of memory
[SQLite return code = 7]
[File = metadata]

This happens most commonly when running the application from within c:\\Program Files on Windows systems. You can work around this by running Recording Service from a command prompt in a directory where you have write permissions.

8.6.2. Segmentation fault after discovering application that uses UserData QoS Policy

If Recording Service discovers an application that has at least one entity (DomainParticipant, DataReader, or DataWriter) that uses the UserData QoS Policy, the behavior is undefined and will likely result in a segmentation fault.

[RTI Issue ID RECORD-1125]