14.4. What’s Fixed in 7.3.0 LTS

This section describes bugs fixed in Routing Service 7.3.0 LTS. These are fixes applied since 7.2.0.

For information on what was fixed in releases 7.0.0, 7.1.0, and 7.2.0, which are also part of 7.3.0 LTS, see Previous Releases.

[Critical]: System-stopping issue, such as a crash or data loss.
[Major]: Significant issue with no easy workaround.
[Minor]: Issue that usually has a workaround.
[Trivial]: Small issue, such as a typo in a log.

14.5. Crashes

14.5.1. [Critical] Segmentation fault when shutting down a Routing Service using <reuse_monitoring_participant> tag

When running an instance of Routing Service that used the <reuse_monitoring_participant> tag, available within the <administration> tag, a segmentation fault occurred on shutting down the service.

[RTI Issue ID ROUTING-1126]

14.5.2. [Critical] Routing Service could crash when an Auto-topic Route’s or Input’s content filter expression was updated remotely

When running a Routing Service configuration that did not provide an initial content filter for an Auto-Topic Route or Input, updating the content filter remotely for that entity could have caused Routing Service to crash.

To update a content filter properly, the Auto-Topic Route or Input should be disabled first, then the content filter can be provided via remote administration. Once the entity is re-enabled, the content filter can be updated remotely without a problem.

Routing Service will no longer crash, and content filter updates will result in a no-op.

[RTI Issue ID ROUTING-1104]

14.5.3. [Critical] Possible race condition and crash in Routing Service when accessing the XML DOM

Routing Service may have crashed when running with a configuration containing Auto Topic Routes and with remote administration enabled. If, while sending remote commands to update an Auto Topic Route, there were discovery events happening and triggering the creation of Topic Routes out of the Auto Topic Route, Routing Service could have crashed and displayed messages similar to the following:

ROUTERCfgFileParser_getEntityQos:entity with name=datawriter_qos not found ROUTERCfgFileStreamPort_getAndConfigureQos:get QoS from profile ROUTERCfgFileAutoTopicRoute_createTopicRouteConfiguration:add topic route configuration ROUTERAutoTopicRoute_matchStream:!create route Process 1249320 (rtiroutingserviceapp) terminated SIGSEGV code=1 fltno=11

[RTI Issue ID ROUTING-1095]

14.5.4. [Critical] Segmentation fault when using Routing Service and Distributed Logger

Previous releases encountered a segmentation fault when using the Routing Service library. This issue occurred when attempting to use the Distributed Logger after deleting an RTI_RoutingService object. The problem occurred because the call to the RTI_RoutingService_delete() operation was deleting the Distributed Logger instance.

If the user application creates the Distributed Logger instance instead of relying on its creation through the <distributed_logger> XML tag used by Routing Service, deleting the Routing Service instance will no longer attempt to delete the Distributed Logger instance.

[RTI Issue ID ROUTING-1079]

14.6. Data Corruption

14.6.1. [Critical] Routing Service did not flag incompatible types when using XML types in the configuration

Routing Service did not flag when using incompatible (non-equivalent) types in the XML configuration of Topic Routes and Routes, with or without transformations. Consider the following XML configuration of a Route:

<route name="Route_TypeCompat">
    <dds_input participant="domain1">
        <creation_mode>IMMEDIATE</creation_mode>
        <registered_type_name>TypeA</registered_type_name>
    </dds_input>
    <dds_output participant="domain2">
        <creation_mode>IMMEDIATE</creation_mode>
        <registered_type_name>TypeB</registered_type_name>
    </dds_output>
</route>

If TypeA and TypeB were not equivalent, it could result in potential data corruption or undefined behavior if there were no custom Processors defined. Routing Service did not perform any static checking on the types while parsing the XML configuration.

Now, when types are defined through XML, Routing Service will perform type-checking for Routes or Topic Routes if they do not include a custom Processor. This extends to the use of Transformations, both on the Inputs and the Outputs.

[RTI Issue ID ROUTING-1161]

14.6.2. [Critical] Routing Service failed to forward samples or published samples with wrong data representation

Routing Service may have failed to forward samples or forwarded samples with the wrong data representation when any of the representations of the input DataReader in a route differed from the representation of the output DataWriter.

For example, you may have configured the input DataReader using the DataRepresentationQosPolicy to accept XCDR and the output DataWriter to publish XCDR2. When the DataWriter published samples with the wrong representation, you may have seen deserialization errors on the application’s DataReaders receiving the samples. These errors occurred only when the topic type on the application’s DataReaders limited the number of supported representations using the allowed_data_representation annotation. For example:

@allowed_data_representation(XCDR2)
struct MyType {
    long my_member;
};

If the application DataReaders were from a different DDS vendor, you may have seen deserialization errors regardless of the allowed_data_representation annotation.

When the DataWriter failed to forward samples, you may have seen errors in DynamicData indicating failures in allocating buffers. For example:

Could not reserve buffer of XYZ bytes

[RTI Issue ID ROUTING-1145]

14.6.3. [Major] Assignment Transformation did not work with derived types

The Assignment Transformation shipped with Routing Service did not work properly with Extensible types. The transformation may not have found fields of a derived type (though it worked fine with fields from the base type).

[RTI Issue ID ROUTING-1141]

14.7. Other

14.7.1. [Critical] Routing Service became non-responsive

Routing Service could have become non-responsive in a domain route. This issue occurred when one of the domain route’s Participants was used both as an input and an output in a route-enabling filter propagation. As a result, the affected domain route’s Participant was not able to send participant announcements to other Participants, leading to liveliness loss with the user application Participants.

[RTI Issue ID ROUTING-1100]

14.7.2. [Critical] Concurrent access to XML DOM from Routing Service Library APIs may have caused corruption or invalid results

The following public APIs in the Routing Service Library accessed the XML configuration DOM without any shared access protection mechanism:

RTI_RoutingService_lookup_processor()
RTI_RoutingService_lookup_xml_entity()

The lack of shared access protection could have caused a corrupted Document Object Module (DOM) or returned invalid results.

Access is now protected with a mutex. This protection ensures that no concurrent access or modification of the XML DOM can occur. This protection does not protect the XML entities obtained from these API calls from being deleted afterwards (for example, via Remote Administration) and, consequently, their pointers becoming obsolete.

[RTI Issue ID ROUTING-1102]

14.7.3. [Critical] Samples not received from Routing Service when route’s output configured to use compression and XCDR2 encapsulation

In previous releases, using XCDR2 encapsulation and compression to configure the DataWriter QoS of a (auto)topic_route’s output did not work. For example, using the following configuration could have led to DataReaders in the system not receiving samples from the DataWriter associated with the (auto)topic_route:

<auto_topic_route name="RouteAll">
  <input participant="domain1">
    <allow_topic_name_filter>*</allow_topic_name_filter>
    <allow_registered_type_name_filter>*</allow_registered_type_name_filter>
  </input>
  <output participant="domain2">
    <allow_topic_name_filter>*</allow_topic_name_filter>
    <allow_registered_type_name_filter>*</allow_registered_type_name_filter>
    <datawriter_qos>
      <representation>
        <value>
          <element>XCDR2_DATA_REPRESENTATION</element>
        </value>
        <compression_settings>
          <compression_ids>LZ4</compression_ids>
        </compression_settings>
      </representation>
    </datawriter_qos>
  </output>
</auto_topic_route>

For DataReaders in the system using ContentFilteredTopic or TopicQueries, you may have seen the following errors in Routing Service.

DDS_SqlFilter_evaluateOnSerialized:deserialization error: sample"

For DataReaders in the system that do not use ContentFilteredTopic or TopicQueries, you may have observed the following deserialization error in their applications:

PRESCstReaderCollator_storeSampleData:deserialize sample error in topic 'MyTopic' with type 'MyType'

[RTI Issue ID ROUTING-1129]

14.7.4. [Major] Routing Service Shell did not print complete product version

Routing Service Shell printed an incomplete and incorrect version:

~$ rtirssh -help
RTI Routing Service Shell 7.2
Usage: rtirssh [options]...

[RTI Issue ID ROUTING-1135]

14.7.5. [Major] Routing Service Socket Adapter example did not properly resolve hostname

The Routing Service Socket Adapter example incorrectly handled the result of the RTIOsapiSocket_getHostByName function. This could have resulted in hostname resolution errors.

[RTI Issue ID ROUTING-1137]

14.7.6. [Minor] <configuration_variables> ignored when used in <types> and <qos_library>

Routing Service failed to start when you used a configuration variable defined in <configuration_variables> within the <types> or <qos_library> sections of the XML configuration. For example:

<?xml version="1.0"?>
<dds>
    <configuration_variables>
        <value>
            <element>
                <name>RWT_PUBLIC_ADDRESS</name>
                <value>192.168.1.2</value>
            </element>
        </value>
    </configuration_variables>

    <qos_library name="RoutingLibrary">
        <qos_profile name="RoutingWANProfile">
            <base_name>
                <element>BuiltinQosSnippetLib::Transport.UDP.WAN</element>
            </base_name>
            <domain_participant_qos>
                <transport_builtin>
                    <udpv4_wan>
                        <public_address>$(RWT_PUBLIC_ADDRESS)</public_address>
                    </udpv4_wan>
                </transport_builtin>
            </domain_participant_qos>
        </qos_profile>
    </qos_library>

    <routing_service>
        ...
    </routing_service>
</dds>

If you provided the previous XML to Routing Service, you would have seen an error similar to the following:

ERROR [/routing_services/default|CREATE] RTIXMLHelper_expandEnvironmentVariables:Undefined environment variable RWT_PUBLIC_ADDRESS
ERROR [/routing_services/default|CREATE] RTIXMLParser_onEndTag:Internal error while parsing line 60: error expanding environment variable
ERROR [/routing_services/default|CREATE] RTIXMLParser_parseFromString_ex:error parsing XML string
ERROR [/routing_services/default|CREATE] ROUTERCfgFileParser_generateNativeExtensionObject:!parse QoS configuration
ERROR [/routing_services/default|CREATE] ROUTERCfgFileParser_initializeExtensionsI:!generate QoS
ERROR [/routing_services/default|CREATE] ROUTERCfgFileParser_processDom:!init parser extensions
ERROR [/routing_services/default|CREATE] ROUTERCfgFileParser_loadUrlGroup:!process DOM
ERROR [/routing_services/default|CREATE] ROUTERCfgFileParser_loadDefaultFiles:Parse error in file '/Users/fernando/RTI/develop/connextdds/installs/Dynamic_Debug/rti_connext_dds-7.3.0/resource/xml/RTI_ROUTING_SERVICE.xml'

[RTI Issue ID ROUTING-1157]