11. Release Notes¶

11.1. Supported Platforms¶

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

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

Table 11.1 Supported Platforms¶
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.
macOS®	All macOS platforms in the RTI Connext DDS Core Libraries Release Notes with the same version number.
QNX®	All QNX Neutrino® 7.0.4 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.

Note: POSIX-compliant architectures that end with “FACE_GP” are not supported.

Recording Service is also supported on the platforms in Table 11.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 11.2 Custom Platforms¶
Platform	Operating System
Linux	Yocto Project® 2.5 on Arm® v8

11.2. Compatibility¶

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

11.3. What’s New in 6.1.0¶

11.3.1. New platforms¶

macOS 10.15 (x64)
Red Hat® Enterprise Linux 7.6 (x64)
Ubuntu® 18.04 LTS (Arm v7 and v8)
Ubuntu 20.04 LTS (x64)
Yocto Project 2.5 (Arm v8) (custom-supported target platform)

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

11.3.2. Removed platforms¶

These platforms are no longer supported:

macOS 10.12
SUSE Linux Enterprise Server 11
Ubuntu 12.04 LTS

11.3.3. New message showing location for output recorded via RTI Launcher¶

When using RTI Launcher to start Recording Service, it was not clear where to find the resulting recorded database. Now you will see a message that indicates the output directory, if you set the verbosity to level 3 or higher.

11.3.4. Ability to replay by recorded source timestamp¶

Now you can replay recorded databases using the recorded source timestamp. For details, see Choosing the Sample Order for Replaying Data.

11.3.5. Instance History Replay¶

Replay Service can now recreate the state of the world prior to a given start timestamp. When this new feature is enabled, Replay Service will publish the latest value known for every instance alive, for keyed topics.

This functionality is currently implemented for the builtin SQLite storage. The Storage API has also been extended to support external plugins.

In the builtin SQLite storage, Recording Service builds an internal index for increased performance. The index is built only once, either:

At recording time
Offline using the utility rtirecordingindexer
At replay runtime

The offline and replay runtime modes are applicable only if the index is not already built.

11.3.6. Ability to index SQLite tables offline¶

This release includes a new command-line utility that will index a database. There is a table indexing mode that will create two SQLite indexes per table, one based on the reception timestamp column and another based on the source timestamp column.

The new script is called rtirecordingindexer.

11.3.7. New debug mode for Replay Service¶

Replay Service can now be started in debug mode. In this mode, you can set breakpoints in the replay. Debug mode allows you to manage the replay on a deeper level than the standard replay mode. See Using Debug Mode while Replaying for details.

To enable debug mode, use the command line option -debugMode or the <debug_mode> tag, like this:

<playback>
      <debug_mode>
          <enabled>true</enabled>
      </debug_mode>
</playback>

11.3.8. Ability to change speed and jump in time during replay¶

Remote Administration gives you more control while replaying data. Now you can change the replay speed, or jump forward/backward in time, without having to restart the replay.

For more information, see Jumping in Time while Replaying and Remote API Overview.

11.3.9. Improved automatic recognition of recorded databases by SQLite tools¶

Recording Service now uses the standard .db file extension by default when creating database files. This change will improve the automatic recognition of these files as SQLite files.

11.3.10. New XML element to wait for acknowledgment¶

When replaying a large database file, Replay Service may shut down before a subscribing application receives all the samples. This can be solved using the new tag <on_delete_wait_for_ack_timeout>.

11.3.11. Repetitive and misleading message repeated at end of recording (rollover not enabled)¶

When Recording Service was used with filesets enabled but no rollover, if the end of the recording was reached (meaning all files in the fileset were completely full with data), a message was continuously printed:

Although this message was benign, it could be misleading. There were no actual errors, but the file size limit was reached, so it was no longer possible to write any more data.

This issue has been resolved. Recording Service will now print just one warning that the end of the fileset has been reached. No recording will happen after that, as expected.

11.3.12. Extended -verbosity command-line parameter to specify service and DDS verbosity independently¶

Recording Service’s -verbosity command-line parameter now allows you to specify separate verbosity levels for service and DDS logs.

For example, you can specify the verbosity as follows:

-verbosity WARN:EXCEPTION

This will set the verbosity to warning level for service logs and exception level for DDS logs.

For more information about -verbosity, see Recording Service Command-Line Parameters or run rtirecordingservice -help.

11.3.13. Service monitoring now reports CPU usage for individual Session threads¶

Service monitoring now includes CPU usage for each thread in a Session’s thread pool. A new optional member has been added to the SessionPeriodic type that includes a sequence of CPU usage for each thread in Session’s thread pool.

11.3.14. Added a Service constructor that receives a shutdown hook¶

Recording Service now has the ability to notify the user when a request to terminate the process is generated, either from remote administration or if the replay completes. The notification is provided through a shutdown hook that can be passed to the service constructor.

See rti::recording::Service for more information.

11.3.15. New API to execute administration commands directly on a Service¶

The rti::recording::Service class has a new operation that allows you to execute administration commands as direct calls on the service. The operation has the following signature:

CommandReply execute_command(const CommandRequest& request);

For details, see Remote Administration.

11.4. What’s Fixed in 6.1.0¶

11.4.1. Non-zero throughput monitoring metrics were provided while service was paused¶

Recording Service provided non-zero throughput monitoring metrics while the service was paused. It provided the number of samples being received by the underlying DataReader. This problem has been resolved. Now when the service is paused, the reported throughput value will be zero.

[RTI Issue ID RECORD-1018]

11.4.2. Executable did not log build ID for DDS libraries¶

The executable version of Recording Service did not log the build ID of DDS libraries, no matter which verbosity level was specified. This was a regression from the previous version, where the build ID was logged for the warning verbosity. This problem has been resolved.

[RTI Issue ID RECORD-1024]

11.4.3. XML Converter, rtixmlconverter, did not show its version properly¶

The XML Converter tool, rtixmlconverter, reported this error if you tried to see its version with rtixmlconverter -version:

main:!parse_before_common:!parse 'must specify conversion of record or replay xml': argument missing

The version was only displayed if you also passed other parameters (record/replay and a configuration filename). This problem has been resolved. Now you can enter rtixmlconverter -version to see the version number.

[RTI Issue ID RECORD-1043]

11.4.4. XMLConverter threw “multiple deserialization modes” warning in some cases¶

XMLConverter (rtixmlconverter) threw the following warning when converting a Recording Service 5.3.1 configuration file:

Warning: Recording Service does not currently support multiple deserialization
modes in a single recording.

This problem has been resolved.

[RTI Issue ID RECORD-1056]

11.4.5. Segmentation fault when using non-compliant XML configuration on a QNX system¶

Using a non-compliant XML configuration with the Recording Service XSD file caused a segmentation fault when trying to process that configuration. This issue, which only occurred on QNX systems, has been resolved.

[RTI Issue ID RECORD-1122]

11.4.6. Segmentation fault after discovering application that used UserData QoS Policy¶

If Recording Service discovered an application that had at least one entity (DomainParticipant, DataReader, or DataWriter) that used the UserData QoS Policy, the behavior was undefined and would likely have resulted in a segmentation fault. This problem has been resolved.

[RTI Issue ID RECORD-1125]

11.4.7. Replay Service did not detect termination correctly¶

Replay Service failed to detect termination correctly under certain conditions. This problem has been resolved.

[RTI Issue ID RECORD-1129]

11.4.8. Windows Debug assertions thrown when running in debug mode¶

Windows debug assertions were sometimes thrown by the debug version of the Replay and Converter executables. This prevented users from running these services successfully on Windows systems when debugging issues. This problem has been resolved.

[RTI Issue ID RECORD-1136]

11.4.9. Monitoring Config Topic contained incomplete information about Topics created from TopicGroups¶

Samples sent on the Config monitoring topic did not include information for recording Topic entities that were created from TopicGroups. The missing information included:

topic_name
registered_type_name
participant_name
topic_group resource ID

This problem has been resolved so the missing information is provided.

[RTI Issue ID RECORD-1146]

11.4.10. Crash if monitoring enabled and TopicGroup matched with Topic name containing ‘/’ character¶

Recording Service crashed if monitoring was enabled and a TopicGroup matched with a Topic name that contained one or more forward slash (‘/’) characters. This problem has been resolved.

[RTI Issue ID RECORD-1153]

11.4.11. Replay Monitoring reported increasing current timestamp while service was paused¶

The current timestamp value provided as part of ServicePeriodic::builtin_sqlite was always increasing, even while the service was paused. However in Replay mode, this value is expected to remain constant while the service is paused. This problem has been resolved.

The following changes in IDL were required:

Deprecated the fields current_timestamp_sec and current_timestamp_nanosec in SqliteDatabasePeriodic. These values are present but will be always set to zero.
Added a new field, current_timestamp_nanos under ServicePeriodic, that represents that current timestamp for both Recording and Replay modes, regardless of the storage being used.

[RTI Issue ID RECORD-1170]

11.4.12. RTI Converter did not properly convert Sequence Numbers from SampleInfo field¶

RTI Converter did not properly process sequence numbers from the SampleInfo field. This caused those fields to always be set to -1 or UINT32_MAX (0xFFFFFFFF). This problem has been resolved.

[RTI Issue ID RECORD-1228]

11.4.13. Recording/Replay Service Crashed when Receiving Wrong Remote Admin Request for Updating Service State¶

Both Recording Service and Replay Service may have crashed when receiving an UPDATE remote administration request to update the service state (e.g., using resource ID /recording_services/<service name>/state or /replay_services/<service name>/state).

If the octet body field of the request was not filled in properly (by serializing the CDR representation of the desired state), and instead contained random data or the serialization of a different type of sample, Recording Service and Replay Service could crash.

This problem has been resolved.

[RTI Issue ID RECORD-1249]

11.5. Known Issues¶

11.5.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:

[/recording_services/RecorderService|START|/storage|CREATE]
 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.