12. Release Notes

12.1. Supported Platforms

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

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

Table 12.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 not supported on SUSE® Linux Enterprise Server or Wind River® Linux 7.
OS X® All OS X 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 12.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 12.2 Custom Platforms
Platform Operating System
Linux Wind River Linux 8 on ARMv7
QNX QNX Neutrino 6.5 on PPC (e500v2)
  QNX Neutrino 7 on ARMv7

12.2. Compatibility

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

12.3. What’s New in 6.0.0

12.3.1. New platforms

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

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

12.3.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 3.5.4.

12.3.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 3.5.6.

12.3.4. Support for C++ Adapter, Transformation and Service APIs

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

See Section 6.

12.3.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 6.

12.3.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 4.

12.3.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 5.

12.3.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'

12.3.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 2.

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

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

12.4. What’s Fixed in 6.0.0

12.4.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]

12.4.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]

12.4.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]

12.4.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]

12.4.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]

12.4.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]

12.4.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]

12.4.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]

12.4.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]

12.5. Known Issues

12.5.1. QoS Topic Filters Not Supported

If the QoS for an Input or Output entity inherits from a base QoS profile that specifies topic filters, these will be ignored in the process of selecting the final parent QoS element.

If the base QoS profile contains multiple QoS elements applicable to an Input or Output, you will need to inherit by specifying the fully qualified name of the desired QoS base element.

[RTI Issue ID ROUTING-37]