.. 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 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. |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 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 Compatibility ------------- For backward compatibility information between |RS| 6.0.1 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.1 ------------------- New platforms ^^^^^^^^^^^^^ |RS| 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. Removed platforms ^^^^^^^^^^^^^^^^^ - macOS 10.11 - Windows 7 - Windows Server 2008 R2 Earlier detection of invalid configurations ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. ROUTING-647 |RS| 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. Added Support for Proxy of TopicQueries in Routes with Multiple Inputs and Outputs ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. ROUTING-667 TopicQuery proxy mode is now supported in TopicRoutes that contain more than one input and/or more than one output. What's Fixed in 6.0.1 --------------------- QoS Topic Filters were not supported ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |RS| 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: .. code-block:: c ... ... ... ... ... ... And the following *Routing Service* configuration: .. code-block:: xml .... MyTopic> MyTopic> ... The corresponding DDS entities below will be created with the QoS that matches the topic filter based on the topic name: .. list-table:: :name: TableRouting37 :widths: 50 25 30 :header-rows: 1 * - 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] Executable did not log build ID for DDS libraries ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The executable version of |RS| 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] 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: ``/collectionA`` The operation failed with an unsupported resource error. Instead, the operation succeeded when the resource identifier was provided as follows: ```` 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] 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: .. code-block:: bash 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] Inconsistent state if remote operation performed on disabled DomainRoute ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If a remote operation was performed on a disabled DomainRoute, |RS| 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] 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 ```` 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] 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: .. code-block:: c dds::sub::DataReader rti::routing::processor::Input::dds_data_reader(); dds::pub::DataWriter 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 ````, or ```` and ````). In this case, you can use these operations as follows: .. code-block:: c using dds::core::xtypes::DynamicData; dds::sub::DataReader input_reader = route.input(0).dds_data_reader(); ... dds::pub::DataWriter output_writer = route.output(0).dds_data_writer(); [RTI Issue ID ROUTING-623] 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] Routing Service failed to detect configuration with duplicate names ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ When loading a configuration file, |RS| 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 ```` entities within the same session have the same name: .. code-block:: xml ... ... This problem has been resolved. Now |RS| will prevent such a configuration from being loaded and will log a message indicating the reason. [RTI Issue ID ROUTING-634] Executable always ignored logging QoS ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Logging settings specified in the DomainParticipantFactory QoS were always ignored when running |RS| 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] Out of memory error if Monitoring enabled on QNX platforms ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ On QNX platforms, you may have received the following output when enabling service monitoring: .. code-block:: bash 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] 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] 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 |RS| 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] Undefined behavior if entity names contained characters ":" or "/" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |RS|'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: .. code-block:: xml ... ... ... ... will generate as Resource identifiers: .. code-block:: xml /routing_services/Service/"DomainRoute/Wan" /routing_services/Service/"DomainRoute::Lan" [RTI Issue ID ROUTING-652] XML variables outside of were not expanded ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |RS| failed to expand any XML variables defined in any element that was not part of the ```` tag, such as those in a ````. This problem has been resolved. All XML variables will be expanded, regardless of their location. [RTI Issue ID ROUTING-653] Previous releases ----------------- 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]