13. Release Notes¶

13.1. Supported Platforms¶

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

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

Table 13.1 Supported Platforms¶
Platform	Operating System
INTEGRITY	INTEGRITY 10.0.2 on x86 CPU
	INTEGRITY 11.0.4 on x86 CPU
Linux®	All Linux platforms in the RTI Connext DDS Core Libraries Release Notes for the same version number, except Wind River® Linux 7.
macOS®	All macOS platforms in the RTI Connext DDS Core Libraries Release Notes for the same version number.
QNX®	All QNX Neutrino® 7.0 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.

Routing Service is also supported on the platforms in Table 13.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 13.2 Custom Platforms¶
Platform	Operating System
Linux	Wind River Linux 8 on Arm® v7 and PPC e6500
	Yocto Project 2.5 on Arm v7
QNX	QNX Neutrino 6.5 on PPC (e500v2)
	QNX Neutrino 7 on Arm v7

13.2. Compatibility¶

For backward compatibility information between Routing Service 6.0.1 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.

13.3. What’s New in 6.0.1¶

13.3.1. New platforms¶

Routing Service now includes support for these platforms:

macOS 10.14 (x64)
QNX Neutrino 7.0 (x64 and Arm v8 x64)
Red Hat® Enterprise Linux 8 (x64)
Wind River Linux 8 (PPC e6500) (custom target platform)
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.

13.3.2. Removed platforms¶

macOS 10.11
Windows 7
Windows Server 2008 R2

13.3.3. Earlier detection of invalid configurations¶

Routing Service successfully loaded configurations that contained an invalid definition. Specifically, it loaded a configuration in which a DomainRoute that contained one or more Sessions but no Participants/Connections. Nevertheless, the service failed to start because the corresponding DomainRoute object failed to instantiate. This problem has been resolved and the service will not load an invalid DomainRoute configuration.

13.3.4. Added Support for Proxy of TopicQueries in Routes with Multiple Inputs and Outputs¶

TopicQuery proxy mode is now supported in TopicRoutes that contain more than one input and/or more than one output.

13.4. What’s Fixed in 6.0.1¶

13.4.1. QoS Topic Filters were not supported¶

Routing 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.

Route’s DDS inputs and outputs
AutoRoute’s DDS input and output
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>...</datawriter_qos>
        <datawriter_qos topic_filter="MyTopic">
             ...
        </datawriter_qos>
        <datareader_qos topic_filter="MyTopic">
             ...
        </datareader_qos>
        <datawriter_qos topic_filter="rti/service/admin/command_reply">
             ...
        </datawriter_qos>
        <datareader_qos topic_filter="rti/service/admin/command_request">
             ...
        </datareader_qos>
        <datawriter_qos topic_filter="rti/service/monitoring/periodic">
             ...
        </datawriter_qos>
    </qos_profile>
</qos_library>

And the following Routing Service configuration:

<routing_service name="MyRouter">
    <administration>
        <writer_qos  base_name="QosLib::QosProfile" />
        <reader_qos base_name="QosLib::QosProfile" />
    </administration>
    <monitoring>
        <writer_qos  base_name="QosLib::QosProfile" />
    </monitoring>

    ....
          <topic_route>
              <input>
                 <topic_name>MyTopic>
                 <reader_qos  base_name="QosLib::QosProfile" />
              </input>
              <output>
                 <topic_name>MyTopic>
                 <writer_qos  base_name="QosLib::QosProfile" />
              </output>
         </topic_route>

         <auto_topic_route>
              <input>
                 <reader_qos  base_name="QosLib::QosProfile" />
              </input>
              <output>
                 <writer_qos  base_name="QosLib::QosProfile" />
              </output>
         </auto_topic_route >
    ...
</routing_service>

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
TopicRoute’s input DataReader	reader QoS	MyTopic
TopicRoute’s output DataWriter	writer QoS	MyTopic
AutoTopicRoute’s input DataReader for topic name=MyTopic	reader QoS	MyTopic
AutoTopicRoute’s output DataWriter for topic name=MyTopic	writer QoS	MyTopic
AutoTopicRoute’s input DataReader for topic name=Other	reader QoS	NULL
AutoTopicRoute’s output DataWriter for topic name=MyTopic	writer 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 ROUTING-37]

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

The executable version of Routing 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 ROUTING-601]

13.4.3. Remote create operation failed with resource identifiers formatted as noted in User’s Manual¶

The remote create operation failed when the resource identifier was formatted as stated in the user’s manual API reference: <parent_resource_id>/collectionA

The operation failed with an unsupported resource error. Instead, the operation succeeded when the resource identifier was provided as follows: <parent_resource_id>

This problem has been resolved. The remote create operation now accepts the resource identifier formatted as indicated in the user’s manual remote API reference. Although syntactically incorrect, it also continues to accept the previous format to preserve backwards compatibility.

[RTI Issue ID ROUTING-603]

13.4.4. Unbounded generation of file handles if monitoring enabled on QNX platforms¶

If monitoring was enabled, a new file handle was periodically generated and never released. Eventually this situation led to the following errors:

DL Debug: : RTIOsapiInterfaceTracker_updateInterfacesUnsafe:!get interfaces failed
DL Error: : ROUTERProcess_getMemoryUsage:!get open /proc/self/as (QNX)
DL Error: : ROUTERProcess_getProcessInfo:!memory usage
DL Error: : ROUTERMonitorableApplication_sampleStatus:!get process info

This problem, which only affected QNX platforms, has been resolved.

[RTI Issue ID ROUTING-614]

13.4.5. Inconsistent state if remote operation performed on disabled DomainRoute¶

If a remote operation was performed on a disabled DomainRoute, Routing Service entered an inconsistent state that may have caused a crash during shutdown or while processing other remote operations. This problem has been resolved.

[RTI Issue ID ROUTING-616]

13.4.6. Changing Session period through Route’s API updated the period, but with a delay¶

Calling the route API to change the period of the parent Session within Processor implementations resulted in a period update delay that was at least equal to the current period. (This periodic event can be enabled via the <periodic_action> tag in XML.)

The observed behavior was that the new period value did not occur until after one more periodic event notifications occurred at the current period value. This problem has been resolved.

[RTI Issue ID ROUTING-620]

13.4.7. Added operations in Processor API to access DataReader/Writer of a DDS input/output¶

The Processor API has been extended with operations to access the underlying DataReader and DataWriter of a DDS input and output, respectively. Namely, the following two operations have been added:

dds::sub::DataReader<Data> rti::routing::processor::Input::dds_data_reader();

dds::pub::DataWriter<Data> rti::routing::processor::Output::dds_data_writer();

You can use these new operations when the Input and Output hold an instance of a DDS StreamReader and DDS StreamWriter, respectively (the case of <topic_route/auto_topic_route>, or <dds_input> and <dds_output>). In this case, you can use these operations as follows:

using dds::core::xtypes::DynamicData;

dds::sub::DataReader<DynamicData> input_reader =
      route.input<DynamicData>(0).dds_data_reader();
...
dds::pub::DataWriter<DynamicData> output_writer =
      route.output<DynamicData>(0).dds_data_writer();

[RTI Issue ID ROUTING-623]

13.4.8. Unexpected routes created after disabling and enabling AutoRoutes¶

Issuing two successive commands to disable and enable an AutoRoute caused the generation of unexpected Routes, if there were already existing and matching streams. This problem has been resolved.

[RTI Issue ID ROUTING-626]

13.4.9. Routing Service failed to detect configuration with duplicate names¶

When loading a configuration file, Routing Service did not detect that the configuration contained more than one entity with the same name and within the same parent configuration. It allowed this configuration to be loaded.

For example, the following is invalid because the <route> entities within the same session have the same name:

<session>
    <route name="Route">...</route>
    <route name="Route">...</route>
</session>

This problem has been resolved. Now Routing Service will prevent such a configuration from being loaded and will log a message indicating the reason.

[RTI Issue ID ROUTING-634]

13.4.10. Executable always ignored logging QoS¶

Logging settings specified in the DomainParticipantFactory QoS were always ignored when running Routing Service with the shipped executable. This problem has been resolved. Now the logging settings are applied and overwritten only when the -logFormat option is provided.

[RTI Issue ID ROUTING-641]

13.4.11. Out of memory error if Monitoring enabled on QNX platforms¶

On QNX platforms, you may have received the following output when enabling service monitoring:

ROUTERProcess_getMemoryUsage:!get Number of entries greater than the limit,
you should consider increasing such limit

This issue occurred because some memory was statically reserved to allocate the data structure necessary to measure memory usage. As the application grew, however, the structure should have also grown, but didn’t. This problem has been resolved. Now the structure is reserved dynamically and can measure bigger applications.

[RTI Issue ID ROUTING-643]

13.4.12. Segmentation fault when reading from custom processor if underlying StreamReader didn’t return SampleInfo list¶

Reading data from an rti::routing::Processor::Input caused a segmentation fault if its underlying rti::routing::adapter::StreamReader returned a NULL sample info list. This problem has been resolved.

[RTI Issue ID ROUTING-645]

13.4.13. Failure to remotely create entity resulted in XML object inserted in loaded DOM¶

If a remote operation to create an entity failed due to an error instantiating the entity object, the associated XML object remained loaded in the service configuration Document Object Model (DOM). This could cause issues such as:

An entity duplication error if a retry to create the entity was issued.
Failures when remotely restarting Routing Service due to an attempt to instantiate the object associated with the XML configuration object.

This problem has been resolved and the service DOM will remain unchanged in case of a creation failure.

[RTI Issue ID ROUTING-646]

13.4.14. Undefined behavior if entity names contained characters “:” or “/”¶

Routing Service’s behavior was undefined if it loaded a configuration that defined elements with a name attribute containing the characters / or :. This issue was caused by a conflict in the generation resource identifiers, which uses / as a resource separator and : as a custom method separator.

This problem has been resolved. If the name of an Entity contains any of these characters (for example, when specified in the name attribute of their corresponding element in XML), the name will be enclosed in double quotation marks (").

For example:

...
<routing_service name="Service">
    <domain_route name="DomainRoute/Wan"> ... </domain_route>
    <domain_route name="DomainRoute::Lan"> ... </domain_route>
</routing_service >
...

will generate as Resource identifiers:

/routing_services/Service/"DomainRoute/Wan"
/routing_services/Service/"DomainRoute::Lan"

[RTI Issue ID ROUTING-652]

13.4.15. XML variables outside of <routing_service> were not expanded¶

Routing Service failed to expand any XML variables defined in any element that was not part of the <routing_service> tag, such as those in a <qos_profile>. This problem has been resolved. All XML variables will be expanded, regardless of their location.

[RTI Issue ID ROUTING-653]

13.5. Previous releases¶

13.5.1. What’s New in 6.0.0¶

13.5.1.1. New platforms¶

Routing Service is now supported on the platforms in Table 13.4. For more information, see the Connext DDS Core Libraries Platform Notes.

Table 13.4 New Platforms¶
Platform	Operating System
Linux	Ubuntu 18.04 LTS on x64
	Wind River Linux 8 on ARMv7 (custom support)

13.5.1.2. Support for multiple connections in a domain route¶

Routing Service has been enhanced to support the creation of more than two connections within a domain route. This includes the ability to specify more than two builtin DDS adapter DomainParticipants.

The XML tags <connection_1>, <connection_2>, <participant_1> and <participant_2> have been deprecated. Routing Service will still load legacy configurations, but support may be dropped in future releases. Instead of these tags, new tags <connection> and <participant> have been introduced. They are defined just like the legacy tags, with the addition of a mandatory ‘name’ attribute. This attribute is used by a route’s input and output to indicate the connection the inputs and outputs are created from. For example, the snippet below defines a domain route with two participants and a custom, adapter-based connection:

<domain_route name="MyDomainRoute">
    <participant name="participant_0">
        ...
    </participant>
    <participant name="participant_1">
        ...
    </participant>
    <connection
        name="customConnection"
        plugin_name="MyAdapteRPlugin>
       ...
    </connection>
    ...
<domain_route>

See Section 4.5.4.

13.5.1.3. Support for multiple inputs and outputs in routes or topic routes¶

Routing Service has been enhanced to support the creation of multiple inputs and outputs in a route. This enhancement includes the ability to specify more than one builtin DDS adapter DataReader (<input>, <dds_input>) and DataWriter (<output>, <dds_output>).

For example, the snippet below defines a topic route with a single input in domain 0 and two outputs in domains 1 and 2 (assume the participants for each input and output have been previously defined):

<topic_route name="Route">
    <input participant="domain_0">
        <topic_name>TopicA</topic_name>
        <registered_type_name>
            MyType
        </registered_type_name>
        ...
    </input>
    <output participant="domain_1">
        <topic_name>TopicB</topic_name>
        <registered_type_name>
            MyType
        </registered_type_name>
        ...
    </output>
    <output participant="domain_2">
        <topic_name>TopicA</topic_name>
        <registered_type_name>
            MyType
        </registered_type_name>
        ...
    </output>
</topic_route>

See Section 4.5.6.

13.5.1.4. Support for C++ Adapter, Transformation and Service APIs¶

Adapter, Transformation and Service APIs are now supported in C++.

See Section 7.

13.5.1.5. New pluggable processor API¶

One of the star features of Routing Service is a new pluggable component, the Processor, which allows you to control the operation and data forwarding logic of Routes.

A Processor defines an interface with access to the Route and its inputs and outputs, allowing you to read, manipulate, and write user data under events such as data arrival or periodic notification.

For example, the following snippet shows a simple example of data aggregation:

on_data_available(Route& route)
{
    auto output = route.output<DynamicData>("info");
    auto info = output.create_data();
    for(const auto& status : route.input<DynamicData>("status_in").take()) {
        auto periodic  = route.input<DynamicData>("periodic_in")
                .select(status.info().instance_handle()).take();
        info.value<int>("id", status.data().get<int>("id"));
        info.value<int>("config", status.data().get<string>("config"));
        info.value<int>("latency", periodic[0].data().get<int>("latency"));
        output.write(info);
    }
}

See Section 7.

13.5.1.6. Redesigned remote administration architecture¶

Routing Service’s remote administration functionality has been redesigned to have a new, consistent, more usable and scalable architecture. Among the changes in this evolution, it includes:

A homogenous API based on REST that standardizes the mechanism to invoke remote operations on the service entities.
A common DDS communication model based on Connext DDS Request-Reply, which is service-independent and represents a common communication channel for all RTI services.
Enhanced administration Topic definitions for increased scalability, with support for content-filtering and instance management.

See Section 5.

13.5.1.7. Redesigned remote monitoring architecture¶

Routing Service’s remote monitoring functionality has been redesigned to have a new, consistent, more usable and scalable architecture. Among the changes in this evolution, it includes:

A common DDS communication model that defines only three Topics to provide all the monitoring information from the service entities. This DDS model is service-independent and a common communication channel for all RTI services.
Enhanced monitoring Topic definitions to represent a more scalable, instance-based mapping between the service entities and their associated monitoring entities.

See Section 6.

13.5.1.8. Support for advanced logging¶

Routing Service internal logging has improved to provide more detailed logging context. With advanced logging, all the operation logs will be part of an activity context that contains information about the entity and the operation. This facilitates the identification of potential issues in the configuration or runtime behavior.

For example, the following log message:

[/routing_services/default|CREATE]

represents a context of a Routing Service create operation. Then any logs generated by operations occurring in this context will be appended to the activity context. For example:

[/routing_services/default|CREATE] load URL group='../../resource/xml/RTI_ROUTING_SERVICE.xml'

13.5.1.9. Support for XML variables expansion from command-line and service API¶

XML configuration variables defined in the form

<element>$(MY_VAR)</element>

can be expanded, in addition to the existing runtime shell environment, from two new mechanisms:

A new command-line option, using the notation -DMY_VAR=my_value
A new ServiceProperty::user_environment member, which represents a map of variable name-value pairs.

See Section 3.

13.5.1.10. Paused and disabled state is cleared after disabling an entity¶

In previous releases, Routing Service remembered the paused state of an entity that was disabled. When that entity was re-enabled, it entered the paused or disabled state. This behavior has changed, so that now the paused state is cleared and if the entity is re-enabled, it will not enter the paused state.

This same behavior affected the child entities of the disabled entity. After re-enabling the entity, Routing Service remembered its state and re-enabled the child entities. This behavior has changed, so that after enabling an entity, each of its child entities is enabled based its own ‘enabled’ attribute.

13.5.1.11. Removed warning caused by multiple registrations of a type¶

Routing Service with Routes using the DDS adapter may have output the following message:

PRESParticipant_registerType:name 'MyTypeRegisteredName ' is not unique

This was caused by multiple registrations of the same type with the same registered name. This behavior has changed and the warning has been removed.

13.5.2. What’s Fixed in 6.0.0¶

13.5.2.1. Remotely disabling TopicRoute/Route could fail while forwarding data¶

A remote command to disable a TopicRoute or Route may have resulted in an error if the TopicRoute or Route was receiving data at a high rate. In this case, the TopicRoute or Route remained enabled and kept forwarding data. This problem has been resolved.

[RTI Issue ID ROUTING-531]

13.5.2.2. Routing Service in debug mode did not link with debug version of Distributed Logger¶

The debug version of Routing Service linked with the release version of the RTI Distributed Logger library, rather than the debug version. This may have lead to unexpected behavior, including potential segmentation faults. This problem has been resolved.

[RTI Issue ID ROUTING-533]

13.5.2.3. Route stream matching not applied correctly in presence of certain partitions¶

When partitions in either the publication or subscription side were composed of patterns only, route streams would not match correctly. This problem has been resolved.

[RTI Issue ID ROUTING-538]

13.5.2.4. Crash on shutdown if types provided through both discovery and XML¶

Routing Service could have randomly crashed during shutdown if it obtained types from both discovery and XML configuration. This problem has been resolved.

[RTI Issue ID ROUTING-539]

13.5.2.5. Sample loan not returned to DDS input upon DDS_DataReader::get_key() failure¶

TopicRoutes did not return the sample loan to the DDS inputs if the StreamReader::read() operation failed due to DataReader::get_key() failures.

This situation could occur very rarely and only if the same StreamReader::read() call returned valid samples in combination with samples discarded by a get_key() failure.

This problem could cause memory growth and errors upon service shutdown. For example, the following logs were the output upon service shutdown:

[D0330|DELETE_CONTAINED]PRESPsService_destroyAllLocalEndpointsInGroupWithCursor:!delete local reader
[D0330|DELETE_CONTAINED]PRESPsService_destroyAllEntities:!destroyAllLocalEndpointsInGroupWithCursor
[D0330|DELETE_CONTAINED]PRESParticipant_destroyAllEntities:!delete service entities
[D0330|DELETE_CONTAINED]PRESParticipant_destroyAllEntities:!delete topic
[D0330|DELETE_CONTAINED]DDS_DomainParticipant_delete_contained_entities:!delete contained entities

This problem has been resolved.

[RTI Issue ID ROUTING-552]

13.5.2.6. Enabling monitoring through ServiceProperty::enable_monitoring only worked if <monitoring> tag present¶

Enabling monitoring by setting ServiceProperty::enable_monitoring did not take effect unless the <monitoring> tag was also part of the XML configuration. This problem has been resolved.

[RTI Issue ID ROUTING-564]

13.5.2.7. Logged message included inaccurate number of dropped samples¶

Routing Service logged a message for a StreamWriter::write failure that included an inaccurate number of dropped samples. For example:

ROUTERRoutingProcessor_routeToMatchingOutputs: write error on output
at index 1. 1024 samples have been dropped

This problem has been resolved.

[RTI Issue ID ROUTING-572]

13.5.2.8. Deserialization errors may have occurred under some conditions¶

Routing Service generated deserialization errors if a publication type was compatible but different than the TopicRoute’s input type, and the TopicRoute’s input was created after the discovery of such publication type. This situation was unlikely to occur. This problem has been resolved.

[RTI Issue ID ROUTING-578]

13.5.2.9. TopicRoutes with TopicQuery proxy mode enabled forwarded live data only to first output¶

A TopicRoute with multiple outputs that enabled TopicQuery proxy mode forwarded live data only to the first output. This problem has been resolved; live data is now forwarded to all outputs.

[RTI Issue ID ROUTING-579]

13.5.2.10. Routing Service Java API did not work with some TypeCodes¶

Types larger than 65,535 bytes and types that used extensible type features only available in TypeObject weren’t properly serialized when using Routing Service’s Java API. This issue caused participant creation to produce a BAD_TYPECODE exception for large types and could have prevented communication between Java applications and applications using a different language binding for types using extensibility features. This problem has been resolved.

[RTI Issue ID ROUTING-583]