14. Release Notes¶

14.1. Supported Platforms¶

RTI Routing Service is supported on the platforms in Table 14.1.

It can also be deployed as a C library linked into your application. This is true for all platforms in Table 14.1 except INTEGRITY®.

Table 14.1 Supported Platforms¶
Platform	Operating System
INTEGRITY	INTEGRITY 10.0.2 and 11.0.4 on x86 CPU. Does not include TCP/IPv4 transport plugin. Implemented as a static C library.
Linux®	All Linux platforms in the RTI Connext DDS Core Libraries Release Notes for the same version number.
macOS®	All macOS platforms in the RTI Connext DDS Core Libraries Release Notes for the same version number.
QNX®	All QNX Neutrino® 7.0.4 platforms in the RTI Connext DDS Core Libraries Release Notes for the same version number.
Windows®	All Windows platforms in the RTI Connext DDS Core Libraries Release Notes for the same version number.

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

Routing Service is also supported on the platforms in Table 14.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 14.2 Custom Platforms¶
Platform	Operating System
Linux	Wind River Linux 8 on Arm® v7.
	Yocto Project 2.5 on Arm v8.
QNX	QNX Neutrino 6.5 on PPC e500v2. Does not include TCP/IPv4 transport plugin.
	QNX Neutrino 7.0.4 on Arm v7 (armv7QNX7.0.0qcc_cxx5.4.0).

14.2. Compatibility¶

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

Routing Service can be used to forward and transform data between applications built with Connext DDS, as well as RTI Data Distribution Service 4.5[b-e], 4.4d, 4.3e, and 4.2e except as noted below.

Routing Service is not compatible with applications built with RTI Data Distribution Service 4.5e and earlier releases when communicating over shared memory. For more information, please see the Transport Compatibility section in the Migration Guide on the RTI Community portal.
Starting in Connext DDS 5.1.0, the default message_size_max for the UDPv4, UDPv6, TCP, Secure WAN, and shared-memory transports changed to provide better out-of-the-box performance. Routing Service also uses the new value for message_size_max. Consequently, Routing Service is not out-of-the-box compatible with applications running older versions of Connext DDS. Please see the RTI Connext DDS Core Libraries Release Notes for instructions on how to resolve this compatibility issue with older Connext DDS applications.
The types of the remote administration and monitoring topics in 5.1.0 are not compatible with 5.0.0. Therefore:
- The 5.0.0 RTI Routing Service shell, RTI Admin Console 5.0.0, and RTI Connext DDS 5.0.0 user applications performing monitoring/administration are not compatible with RTI Routing Service 5.1.0.
- The 5.1.0 RTI Routing Service shell, RTI Admin Console 5.1.0, and RTI Connext DDS 5.1.0 user applications performing monitoring/administration are not compatible with RTI Routing Service 5.0.0.

14.3. What’s New in 6.1.0¶

14.3.1. New platforms¶

macOS 10.15 (x64)
QNX Neutrino 7.0.4 (Arm v7) (custom-supported target platform)
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.

14.3.2. Removed platforms¶

These platforms are no longer supported:

macOS 10.12
SUSE Linux Enterprise Server 11
Ubuntu 12.04 LTS

14.3.3. Improved behavior if –verbosity set above the allowed maximum¶

Setting the command-line option -verbosity higher than the maximum, which is 6, will now be treated as if set to the maximum. Previously, using a higher value resulted in a lower verbosity than expected.

14.3.4. 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 a Session’s thread pool.

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

Routing 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 -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 Routing Service Command-Line Parameters or run the executable with the -help option (rtiroutingservice -help).

14.3.6. New command-line option to save log in a file¶

Routing Service has a new command-line option, -logFile <file_name>, that will save its log in a file.

14.3.7. New message logging API, integrated with service logging system¶

The Routing Service SDK has a new message logging API that is integrated with the service’s logging system. Messages logged with this API will be interpreted as if they were generated by the service itself. This means these messages can be sent with Distributed Logger and the logging settings will apply to them as well.

The new API is available in C and C++.

In C:

void RTI_RoutingServiceLogger_log(
        NDDS_Config_LogLevel log_level,
        const char *format,
        ...);

In C++, the rti::routing:::Logger class has been extended with operations to log a message for each log level:

void :error(const std::string& msg);
void  warn(const std::string& msg);
...

You can use the new API to log messages from custom Adapters, Processors, Transformations, and applications embedding a service with the Service API. Using this API requires linking against the service library.

14.3.8. New APIs to get/set DynamicType from/in StreamInfo object¶

The Routing Service C++ SDK has new APIs to get/set a DynamicType from/in a TypeInfo. The APIs have the following signature:

const dds::core::xtypes::DynamicType& TypeInfo::dynamic_type() const;

void dynamic_type(const dds::core::xtypes::DynamicType *dynamic_type);

You can use these APIs to develop Adapters, Processors, and Transformations.

14.3.9. Ability to define default values for variables in XML configuration¶

In previous versions, XML variables expressed in the form $(MY_VAR) were expanded by obtaining values from the process environment of the ServiceProperty::user_environment. Loading the configuration failed if a variable was not defined by any of these means.

To allow you to assign default values to the XML variables, a new <configuration_variables> element is allowed within the <dds> root tag, as follows:

<configuration_variables>
    <value>
        <element>
            <name>MY_VAR</name>
            <value>my default value</value>
        </element>
    </value>
</configuration_variables>

The specification of <configuration_variables> must appear before a variable is used. The default value will be used if no other value is found from the aforementioned means.

Additionally, for convenience you can specify <configuration_variables> in a separate file (that appears first in the file loading order).

14.3.10. Removed duplicate symbols in rtirsinfrastructure and rtiroutingservice libraries¶

The libraries rtirsinfrastructure and rtiroutingservice included multiple duplicate symbols. This caused a warning in applications that linked against both of them. This problem has been resolved.

14.3.11. Enhanced logging information for each written sample¶

Routing Service will include additional logging information for each sample that is written to a DDS output. The information includes the Writer GUID and Sequence Number. For example:

[/routing_services/MyRouter/domain_routes/DomainRoute/sessions/MySessions/routes/MyRoute] write: {GUID: {1020304 5060708 1020304 5060708}, SN : {0, 1}}

The additional information can only be obtained when using CONTENT verbosity.

14.3.12. Register type and content filter tags now consistent with DDS-XML specification¶

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

<registered_type> has been renamed to <register_type> and there are changes to its possible attributes and elements.
The possible attributes and elements for <content_filter> have changed.

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

14.3.13. Periodic event is now configurable individually per Route¶

A periodic event can 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> 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.

14.3.14. Added LoanedSamples::has_infos()¶

A new operation has been added to the LoanedSamples in the Processor API with the following signature:

bool LoanedSamples::has_infos()

The new operation returns whether the underlying Input can read Samples that contain SampleInfo objects. This information can help Processor implementations to be robust to any underlying Adapter implementation.

14.3.15. New API to get a Route’s name, Route::full_name¶

There is a new operation in the Route class that returns its fully qualified name, derived from the configuration. The operation has the following signature (in C++):

const std::string& std::string Route::full_name() const;

14.3.16. Increased verbosity for log message “ROUTERDdsConnection_assertType:two different type definitions…”¶

Routing Service logged the following message with a WARNING verbosity:

ROUTERDdsConnection_assertType:two different type definitions with the
same name (<type_name>) were found

But this problem could occur if different extended versions of a type were received. Therefore, the verbosity has changed to the highest possible value (DEBUG).

14.3.17. Support for Input Transformation¶

An Input can now include a pluggable Transformation. The configuration is similar to an Output. For example:

<input>
   ...
   <transformation plugin_name="my_transf_plugin">
       <property>...</property>
   </transformation>
</input>

14.3.18. Several improvements in monitoring and administration infrastructure¶

Routing Service’s monitoring and administration infrastructure has been improved with the following additions:

Monitoring and Administration types are available in XML format too. You can find them under <NDDSHOME>/resource/xml.
Monitoring and Administration can share a participant. The new tag <reuse_monitoring_participant> under <administration> configures this behavior.
Monitoring and Administration data can be routed from the same Routing Service instance.

14.3.19. New XML element to wait for acknowledgment¶

When routing large samples, Routing Service may have shut down before a subscribing app received all the samples. You can avoid this by using the new <on_delete_wait_for_ack_timeout> tag.

14.3.20. Ability to disable data on inputs event within routes/auto routes¶

(Topic)Routes and Auto(Topic)Routes can now be configured to disable notification of data on inputs events. For example, the following XML disables this event:

<route>
    <enable_data_on_inputs>false</enable_data_on_inputs>
<route>

This configures the route so that the processor will not receive notifications of new data. Therefore another mechanism to process data is required, such as enabling a periodic event.

14.4. What’s Fixed in 6.1.0¶

14.4.2. XML validation failed if allow/deny filter names in AutoRoutes contained whitespaces or new lines¶

Routing Service failed to validate the XML configuration if any of these tags in AutoRoutes contained whitespaces or new lines:

<allow_topic_name_filter>
<allow_type_name_filter>
<deny_topic_name_filter>
<deny_type_name_filter>

For example:

<allow_topic_name_filter>
     A Topic, B Topic,
     Other Topic

This problem has been resolved. Now allow/deny filters can include whitespaces and new-line characters.

[RTI Issue ID ROUTING-617]

14.4.3. Routing Service crashed if monitoring participant creation failed¶

Routing Service may have crashed during initialization if the monitoring participant creation failed. This problem has been resolved.

[RTI Issue ID ROUTING-666]

14.4.4. Possible segmentation fault after failure to create Adapter Session, StreamReader, or StreamWriter¶

If there was a failure creating an Adapter Session, StreamReader, or StreamWriter, this may have resulted in a segmentation fault. This behavior was timing dependent and only occurred if multiple Sessions were defined within a DomainRoute. This problem has been resolved.

[RTI Issue ID ROUTING-679]

14.4.5. Assertion failed while reading data from an Input on Windows platform¶

A Processor running in debug mode caused an assertion failure when reading data from an input on Windows platforms. This problem has been resolved.

[RTI Issue ID ROUTING-687]

14.4.6. -convertLegacyXml option failed on Windows systems if no output path specified¶

The -convertLegacyXml option failed on Windows systems if an output path was not specified. This problem has been resolved.

[RTI Issue ID ROUTING-710]

14.4.7. Report of aggregated monitoring statistics contained invalid data¶

The monitoring metrics that Routing Service computes and reports may have contained invalid and incoherent values for statistics that were represented as aggregations of other variables (e.g., throughput for a Session). This report of invalid values was caused by a very rare race condition. This problem has been resolved.

[RTI Issue ID ROUTING-716]

14.4.8. Error re-enabling a route that was updated while disabled¶

A Route that contained at least one input or output with no QoS tag could not be disabled and re-enabled with remote administration. This problem has been resolved.

[RTI Issue ID ROUTING-725]

14.4.9. rtirssh crashed if load command was sent¶

The Routing Service remote shell, rtirssh crashed if a load command was sent. This problem has been resolved.

[RTI Issue ID ROUTING-773]

14.4.10. Unexpected “DDS_SqlTypeSupport_deserialize_Union:!deserializing union type” exception¶

Routing Service may have generated the following exception when sending or receiving samples:

DDS_SqlTypeSupport_deserialize_Union:!deserializing union type

This condition only occurred in routes with a type containing unions, and only when <memory_management>/<sample_buffer_min_size> was finite (not LENGTH_UNLIMITED).

In addition, any of these conditions had to be true:

<content_filter> was configured.
The route’s DataWriter QoS was configured to enable TopicQueries.
The route’s DataWriter(s) matched with a DataReader created on a ContentFilteredTopic.

This problem has been fixed.

[RTI Issue ID ROUTING-781]

14.4.11. Crash when publishing a stream with different type names and using auto-route with monitoring¶

Using an auto_route with monitoring enabled lead to a crash if you published data on the same stream name (topic for DDS domains) with multiple type name definitions.

In general, it is not advised to have multiple type definitions for the same stream when dealing with auto_routes, since that can lead to creation of routes with mismatched streams discovered on the input and output side. This problem has been resolved and the crash will no longer occur.

[RTI Issue ID ROUTING-798]

14.4.12. Segmentation fault when attempting to enable a session with a disabled parent domain route¶

Routing Service terminated with a segmentation fault if you attempted to remotely enable a disabled Session that also had a disabled parent Domain Route. This issue has been resolved.

[RTI Issue ID ROUTING-789]

14.4.13. QoS Profiles in NDDS_QOS_PROFILES.xml were not loaded¶

In previous releases, the file NDDS_QOS_PROFILES.xml was not loaded, due to an incorrect path in the code.

This problem has been resolved. Now if this file exists, it will be properly loaded and you can refer to the file’s QoSs or QoS Profiles in your Routing Service XML configuration.

[RTI Issue ID ROUTING-811]

14.4.14. Unnecessary network bandwidth for participant announcements generated by Routing Service¶

In previous releases, the DomainParticipant created by Routing Service generated RTPS DATA(P) messages larger than necessary due to the addition of a property called dds.content_filter.sql.deserialized_sample.min_buffer_size.

This issue has been fixed and the DATA(P) messages no longer contain this property.

[RTI Issue ID ROUTING-813]

14.5. Known Issues¶

14.5.1. Attempting to route builtin Security Logging topic causes Routing Service crash¶

Routing the Security Logging builtin topic (DDS:Security:LogTopic) causes a crash if any of the participants involved in the route have security logging enabled (i.e., the property com.rti.serv.secure.logging.distribute.enabled is set to true).

Note that you can enable security logging on participants that talk to Routing Service and even route the Security Logging builtin topic that they use. This problem occurs only if the Routing Service participant itself has security logging enabled.

[RTI Issue ID ROUTING-727]