14.5.3. What’s new in 6.1.0 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. Removed platforms

These platforms are no longer supported:

  • macOS 10.12

  • SUSE Linux Enterprise Server 11

  • Ubuntu 12.04 LTS 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. 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. 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). 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. 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. 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. 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:

            <value>my default value</value>

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). 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. 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. 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. Periodic event is now configurable individually per Route

A periodic event can be individually enabled and configured for each Route as follows:


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. 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. 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; 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). Support for Input Transformation

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

   <transformation plugin_name="my_transf_plugin">
</input> 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. 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. 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:


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.