.. include:: vars.rst .. _section-release-notes: Release Notes ============= Supported Platforms -------------------- |RTI_RS| is supported on the platforms in :numref:`TableSupportedPlatforms`. It can also be deployed as a C library linked into your application. This is true for all platforms in :numref:`TableSupportedPlatforms` except INTEGRITY. .. list-table:: Supported Platforms :name: TableSupportedPlatforms :widths: 20 80 :header-rows: 1 * - 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. |RS| is also supported on the platforms in :numref:`TableCustomPlatforms`; 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. .. list-table:: Custom Platforms :name: TableCustomPlatforms :widths: 20 80 :header-rows: 1 * - Platform - Operating System * - Linux - Wind River Linux 8 on ARMv7 * - QNX - QNX Neutrino 6.5 on PPC (e500v2) * - - QNX Neutrino 7 on ARMv7 Compatibility ------------- For backward compatibility information between |RS| 6.0.0 and previous releases, please see the *Migration Guide* on the `RTI Community portal `_. |RS| can be used to forward and transform data between applications built with |CONNEXT|, as well as *RTI Data Distribution Service* 4.5[b-e], 4.4d, 4.3e, and 4.2e except as noted below. - |RS| 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| 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. |RS| also uses the new value for ``message_size_max``. Consequently, |RS| is not out-of-the-box compatible with applications running older versions of |CONNEXT|. Please see the *RTI Connext DDS Core Libraries Release Notes* for instructions on how to resolve this compatibility issue with older |CONNEXT| 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. What's New in 6.0.0 ------------------- New platforms ^^^^^^^^^^^^^ |RS| is now supported on the platforms in :numref:`TableNewPlatforms`. For more information, see the |CONNEXT| *Core Libraries Platform Notes*. .. list-table:: New Platforms :name: TableNewPlatforms :widths: 20 80 :header-rows: 1 * - Platform - Operating System * - Linux - Ubuntu 18.04 LTS on x64 * - - Wind River Linux 8 on ARMv7 (custom support) Support for multiple connections in a domain route ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |RS| 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 , , and have been deprecated. |RS| will still load legacy configurations, but support may be dropped in future releases. Instead of these tags, new tags and 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: .. code-block:: xml ... ... TopicA MyType ... TopicB MyType ... TopicA MyType ... See :numref:`section-Config-Route`. Support for C++ Adapter, Transformation and Service APIs ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Adapter, Transformation and Service APIs are now supported in C++. See :numref:`section-sdk`. New pluggable processor API ^^^^^^^^^^^^^^^^^^^^^^^^^^^ One of the star features of |RS| is a new pluggable component, the *Processor*, which allows you to control the operation and data forwarding logic of |ROUTE|\s. 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: .. code-block:: C++ on_data_available(Route& route) { auto output = route.output("info"); auto info = output.create_data(); for(const auto& status : route.input("status_in").take()) { auto periodic = route.input("periodic_in") .select(status.info().instance_handle()).take(); info.value("id", status.data().get("id")); info.value("config", status.data().get("config")); info.value("latency", periodic[0].data().get("latency")); output.write(info); } } See :numref:`section-sdk`. Redesigned remote administration architecture ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |RS|'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| *Request-Reply*, which is service-independent and represents a common communication channel for all |RTI_SERVICE|\s. - Enhanced administration |TOPIC| definitions for increased scalability, with support for content-filtering and instance management. See :numref:`section-Admin`. Redesigned remote monitoring architecture ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |RS|'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** |TOPIC|\s to provide all the monitoring information from the service entities. This DDS model is service-independent and a common communication channel for all |RTI_SERVICE|\s. - Enhanced monitoring |TOPIC| definitions to represent a more scalable, instance-based mapping between the service entities and their associated monitoring entities. See :numref:`section-Monitoring`. Support for advanced logging ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |RS| 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: .. code-block:: bash [/routing_services/default|CREATE] represents a context of a |RS| create operation. Then any logs generated by operations occurring in this context will be appended to the activity context. For example: .. code-block:: bash [/routing_services/default|CREATE] load URL group='../../resource/xml/RTI_ROUTING_SERVICE.xml' .. //TODO add reference to logging section once is available. Support for XML variables expansion from command-line and service API ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ XML configuration variables defined in the form .. code-block:: bash $(MY_VAR) 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 :numref:`section-Usage`. Paused and disabled state is cleared after disabling an entity ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. ROUTING-576 In previous releases, |RS| 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, |RS| 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. Removed warning caused by multiple registrations of a type ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. ROUTING-573 |RS| with Routes using the DDS adapter may have output the following message: .. code-block:: bash 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. What's Fixed in 6.0.0 --------------------- 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] Routing Service in debug mode did not link with debug version of Distributed Logger ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The debug version of |RS| 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] 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] Crash on shutdown if types provided through both discovery and XML ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |RS| 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] 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: .. code-block:: bash [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] Enabling monitoring through ServiceProperty::enable_monitoring only worked if tag present ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Enabling monitoring by setting ServiceProperty::enable_monitoring did not take effect unless the tag was also part of the XML configuration. This problem has been resolved. [RTI Issue ID ROUTING-564] Logged message included inaccurate number of dropped samples ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |RS| logged a message for a StreamWriter::write failure that included an inaccurate number of dropped samples. For example: .. code-block:: bash ROUTERRoutingProcessor_routeToMatchingOutputs: write error on output at index 1. 1024 samples have been dropped This problem has been resolved. [RTI Issue ID ROUTING-572] Deserialization errors may have occurred under some conditions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |RS| 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] 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] 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] Known Issues ------------ 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]