.. include:: ../../router.1.0/srcDoc/vars.rst

.. _section-Regressions:


Regressions
***********

The following regressions are introduced in 6.0.0.

RTI Connext DDS Core Libraries
==============================

Issues in the Core Libraries may affect components that use these libraries, 
including services and tools.

.. _section-xml-compatibility:

XSD issues
----------

Order enforced in <domain_participant> tag
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In 6.0.0, the XSD definition file https://community.rti.com/schema/6.0.0/rti_dds_profiles.xsd,
which is used by all |CONNEXT| products, including |CONNEXT| *Micro*, now
enforces a specific ordering for tags within the ``<domain_participant>`` tag in the
``<doman_participant_library>`` tag.

The following XML example was valid in 5.3.1, but not in 6.0.0:

.. code-block:: xml

    <?xml version="1.0" encoding="UTF-8"?>
    <dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="https://community.rti.com/schema/6.0.0/rti_dds_profiles.xsd">  <!-- QoS Profiles -->
        <qos_library name="QosLibrary">
            ...
        </qos_library>  <!-- Domains -->
        <domain_library name="DomainLibrary">
            <!-- Shape -->
            <domain name="Shape" domain_id="0">
                ...
        </domain>  <!-- Participants -->
        <domain_participant_library name="DomainParticipantLibrary">
            <!-- Shape -->
            <domain_participant name="ShapePublisher" domain_ref="DomainLibrary::Shape">
                <participant_qos base_name="QosLibrary::Base">
                    ...
                </participant_qos>
                <publisher name="Publisher">
                  ...
                </publisher>
            </domain_participant>
            <domain_participant name="ShapeSubscriber" domain_ref="DomainLibrary::Shape">
                <participant_qos base_name="QosLibrary::Base">
                  ...
                </participant_qos>
                <subscriber name="Subscriber">
                  ...
                </subscriber>
           </domain_participant>
       </domain_participant_library>
    </dds>

The validation of this example using the XSD
(https://community.rti.com/schema/6.0.0/rti_dds_profiles.xsd) will fail because
the ``<publisher>`` tag should now appear before the ``<participant_qos>`` tag.

For example, using the above XML in |RS| 6.0.0 will raise the
following errors:

.. code-block:: bash

    [/routing_services/default|CREATE] line XXX: Element 'publisher': This element is not expected.
    [/routing_services/default|CREATE] line XXX: Element 'subscriber': This element is not expected.

This problem will be fixed in release 6.0.1.

[RTI Issue ID CORE-9306]


.. _section-xml-compatibility-publisher:

Order enforced in <publisher> tag
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In 6.0.0, the XSD definition file https://community.rti.com/schema/6.0.0/rti_dds_profiles.xsd,
which is used by all |CONNEXT| products, including |CONNEXT| *Micro*, now
shows an error when the ``<data_writer>`` or ``<data_reader>`` tag is placed after 
the ``<publisher_qos>`` or ``<subscriber_qos>`` tag:

.. code-block:: bash

    "The element 'publisher' has invalid child element 'data_writer'.":

The following XML snippet was valid in 5.3.1, but now gives an error in 6.0.0:

.. code-block:: xml

    <publisher name="MyPublisher">
        <publisher_qos/>
        <data_writer name="MyWriter" topic_ref="MyTopic">
            <datawriter_qos base_name="MyQos"/>
        </data_writer>
    </publisher>
 
To avoid this error, change your XML as follows:

.. code-block:: xml

    <publisher name="MyPublisher">
        <data_writer name="MyWriter" topic_ref="MyTopic">
            <datawriter_qos base_name="MyQos"/>
        </data_writer>
        <publisher_qos/>
    </publisher>

This problem will be fixed in an upcoming patch.

[RTI Issue ID CORE-9374]


.. _section-xml-compatibility-alphanumeric:

XSD validation fails if topic_ref or register_type_ref uses some non-alphanumeric characters
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In 6.0.0, XSD validation of an XML application creation file now fails if there are |DW| ``topic_ref`` 
and ``register_type_ref`` attributes using non-alphanumeric characters such as '#'.

The only strings allowed are those matching this pattern: 

.. code-block:: bash

     ((::)?[a-zA-Z0-9_.])+

If you want to use non-alphanumeric characters to specify the 
name of a *Topic* (although doing so is non-compliant with the OMG DDS standard), use the  
``<registered_name>`` tag, which is available in both ``<register_type>`` and ``<topic>`` tags. 
For example:

.. code-block:: xml

    ...
    <domain_participant name="participant">
        ...
        <topic name="MyTopic" register_type_ref="regType">
            <registered_name>com/rti/example/MyTopic</registered_name>
        </topic>
        ...
       <data_writer name="writer" topic_ref="MyTopic"/>
    </participant>
    ...

This problem will be fixed in release 6.0.1 to allow the non-alphanumeric characters.

[RTI Issue ID CORE-9484]


.. _section-frag-error:


Dynamic Data issues
-------------------

.. _section-9653:

Segmentation fault when using unkeyed DynamicData |DR| with content filter and writer-side filtering
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In 6.0.0, a |DR| may receive samples that do not match the content filter 
being used by the |DR|, even if the |DW| is performing writer-side filtering. 
This could happen for two reasons:

* The |DR| changes its filter after the |DW| writes the sample, and the sample passes 
  the |DR|'s previous filter.
* There is another |DR| at the same locator that should receive the sample.

An unkeyed DynamicData |DR| that receives a sample due to the second reason above 
may segfault while attempting to return the sample resources after dropping 
the filtered sample.

This problem will be fixed in release 6.0.1.

[RTI Issue ID CORE-9653]


Invalid serialization of samples with types containing primitive members that require padding
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
See more information in :numref:`section-codegen-serialize-sample`.


.. _section-9821:

Possible data corruption or crash when using DynamicData and a type with inheritance
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In 6.0.0, when using DynamicData and a type with inheritance, there is a possibility for data 
corruption or a crash when receiving the data. This error happens if the inherited 
base type contains one or more members of the following types:

* A sequence of complex members (structs, sequences, unions, array)
* An optional member of a complex type

The complex members mentioned above have to themselves contain at least one of:

* a string
* a sequence (of any kind)
* an optional member

In addition, if the complex member is mutable, any member of the complex member that 
is not explicitly sent will not be initialized during deserialization to the correct 
default value if the default is something other than 0 (for example, through the use of 
the @default annotation or an enumeration with a non-zero default enumerator).

For example, the following type may exhibit this behavior because the BaseType contains 
a sequence of complex members that contain a string:

.. code-block:: text

    struct ComplexMember {
        string myString;
    };

    struct BaseType {
        sequence<ComplexMember> myComplexSequence;
    };

    struct DerivedType : BaseType {
        long myLong;
    };

This problem will be fixed in release 6.0.1.

[RTI Issue ID CORE-9821]


Discovery does not complete, and there is no error
--------------------------------------------------
In 5.3.1 and below, |DP| announcement messages (DATA(P)) could be sent on the 
wire as long as the message size, including the RTPS overhead, was not greater 
than the smallest ``message_size_max`` value across all installed transports. If the 
message size exceeded this limit, you would have seen the following error:

.. code-block:: text

    PRESPsWriter_writeInternal:!failed to write sample in Commend
    DISCSimpleParticipantDiscoveryPluginPDFListener_onAfterLocalParticipantEnabled:!write
    MIGGenerator_addData:serialize buffer too small
    COMMENDAnonWriterService_onDomainBroadcastEvent:!add DATA to MIG

In 6.0.0, this behavior changed such that if the size of the DATA(P) messages 
without including the RTPS overhead, minus 512 bytes, is greater than the smallest 
``message_size_max`` value across all installed transports, the message is incorrectly 
fragmented by the builtin |DW|. Additionally, since the builtin ParticipantBuiltinTopicData 
|DR| does not support fragmentation, it fails to reassemble the fragmented messages, 
and discovery does not complete. No error is printed, either.

Practically speaking, the maximum size of the DATA(P) messages that can be sent on the 
wire is reduced in 6.0.0. Messages that would have made it through in 5.3.1 do not in 6.0.0.

This problem will be fixed in release 6.0.1. 

.. note::

    When |DP| announcements need to be fragmented, discovery does not complete 
    in any release. The solution in any release is to increase the transport 
    ``message_size_max`` property or decrease the size of the |DP| announcements.

[RTI Issue ID CORE-9872]


.. _section-qos-crash:

Crash when deserialized_type_object_dynamic_allocation_threshold set to 0
-------------------------------------------------------------------------
In 6.0.0, |CONNEXT| applications that set 
``deserialized_type_object_dynamic_allocation_threshold`` to zero (in the 
DomainParticipantQos's ResourceLimits QosPolicy) may crash if 
``endpoint_type_object_lb_serialization_threshold`` in the 
DomainParticipantQos's  ``DISCOVERY_CONFIG`` QosPolicy is set to a value other 
than -1.

This problem will be fixed in release 6.0.1.

[RTI Issue ID CORE-9532]



.. |dw.get_matched_sub| replace:: DDS::DataWriter::get_matched_subscription_data
.. |dr.get_matched_pub| replace:: DDS::DataReader::get_matched_publication_data

Wrong return code for |dw.get_matched_sub| and |dr.get_matched_pub|
-------------------------------------------------------------------

In 6.0.0, ``DDS::DataWriter::get_matched_subscription_data`` and
``DDS::DataReader::get_matched_publication_data`` incorrectly return
``DDS_RETCODE_ERROR`` instead of ``DDS_RETCODE_PRECONDITION_NOT_MET`` when the
instance handle does not correspond to any matched endpoint. This problem
may affect application logic that was expecting ``DDS_RETCODE_PRECONDITION_NOT_MET``.
This problem also affects APIs that use exceptions instead of return codes
(modern C++, Java, and .NET). 

This problem will be fixed in release 6.0.1.

[RTI Issue ID CORE-9232]



.. _section-coherent-set-bug:

DataReader reports incorrect sample lost and rejected when receiving coherent set
----------------------------------------------------------------------------------
In 6.0.0, there is an issue that provokes |DRs| receiving a coherent set to incorrectly 
increment the sample lost and sample rejected count statistics, and to incorrectly 
call the ``onSampleLost()`` and ``onSampleRejected()`` callbacks. When this issue 
is triggered, the following warnings are logged:

.. code-block:: text

    PRESCstReaderCollator_addCollatorEntryToPolled:!assert instance
    PRESCstReaderCollator_assertInstance:!keyhash not available, dropping the sample...

This issue will be fixed in release 6.0.1.

[RTI Issue ID CORE-9576]


.. _section-qos-incorrect:

QoS policies not resolved to correct values
-------------------------------------------
In 6.0.0, the implementation of Qos Profile composition 
(see “XML multiple inheritance” in :link_connext_whats_new:`What's New in 6.0.0 <>`)
introduced a regression. Consider this example:

.. code-block:: xml

    <qos_profile name="Parent">
        <datawriter_qos name="DW_InParent" base_name="BuiltinQosLibExp::Generic.StrictReliable">
        <!-- Values specified by DW_InParent -->
        </datawriter_qos>
    </qos_profile>

    <qos_profile name="Child">
        <datawriter_qos name="DW_IncorrectValues" base_name="Parent" />
    </qos_profile>

In this example, "DW_IncorrectValues" points to "Parent," which is not a 
``<datawriter_qos>`` but a ``<qos_profile>``. Therefore, |CONNEXT| should inherit 
values from the following elements, in order:

#. BuiltinQosLibExp::Generic.StrictReliable (and its parents, and their parents if any)
#. Values set in XML by "DW_InParent"

There is a problem, however, with the way |CONNEXT| populates parents 
in this scenario. As a result, |CONNEXT| only copies values 
set in XML by "DW_InParent," ignoring the QoS parent value "BuiltinQosLibExp::Generic.StrictReliable" 
specified in the ``base_name`` attribute, giving incorrect results. 

A workaround is to change your XML file so that ``<xxx_qos>`` points directly to another ``<xxx_qos>`` 
and not a ``<qos_profile>``. In this example, you would make the following correction:

.. code-block:: xml

    <qos_profile name="Child">
        <datawriter_qos name="DW_IncorrectValues" base_name="DW_InParent" />
    </qos_profile>

This problem will be resolved in 6.0.1 by fixing the internal logic to populate parent values correctly. 
After the fix, when the inherited ``<qos_profile>`` contains an <xxx_qos> having its own ``base_name`` 
attribute value, |CONNEXT| will find and return the correct QoS values.

For more information on QoS Profile Inheritance, see 
:link_connext_inherit_usersman:`the "QoS Profile Inheritance" section in the RTI Connext DDS Core Libraries User's Manual <>`.

[RTI Issue ID CORE-9376]


RTI Security Plugins
====================

Possible lack of SUBSCRIPTION_MATCHED_STATUS if a DataWriter loses liveliness with the DataReader
-------------------------------------------------------------------------------------------------

In 6.0.0, there is a race condition in which a |DR| may never report a
SUBSCRIPTION_MATCHED_STATUS change despite successfully matching and receiving
data from a |DW|. This race condition occurs if all of the following
conditions are true:

   * The |DR| sets its liveliness ``lease_duration`` to a very small
     duration (on the order of milliseconds).
   * The |DR| is communicating with a |DW| with
     ``metadata_protection_kind`` or ``data_protection_kind`` set to a value
     other than NONE.
   * The |DW| loses liveliness with the |DR| between the time
     the |DR| discovers the |DW| and the time the |DR|
     receives key material from the |DW|.
   * The |DW| regains liveliness with the |DR| before the
     |DR| receives key material from the |DW|.

     .. note::

                 This condition is the opposite of the fourth
                 condition in RTI Issue ID SEC-895,
                 which is fixed in 6.0.0. (See
                 :link_connext_sec_fix_other_release_notes:`What's Fixed in 6.0.0
                 in the Security Plugins Release Notes <>`.)

This problem will be fixed in release 6.0.1.

[RTI Issue ID SEC-911]


.. _section-security-1013:

|DW| does not report PUBLICATION_MATCHED_STATUS for |DRs| that are inactive when it receives their key material
---------------------------------------------------------------------------------------------------------------

In 6.0.0, under the following sequence of events, a |DW| setting ``<metadata_protection_kind>`` 
or ``<data_protection_kind>`` to a value other than NONE never reports 
PUBLICATION_MATCHED_STATUS for a |DR|:

#. The |DW| discovers the |DR|.
#. The |DR| becomes inactive after ``writer_qos.protocol.rtps_reliable_writer.max_heartbeat_retries`` 
   Heartbeats (HBs) due to the lack of response to HBs (default behavior) or to 
   not making progress on the NACK messages (non default - requires setting 
   ``writer_qos.protocol.rtps_reliable_writer.inactivate_nonprogressing_readers`` 
   to TRUE).
#. The |DW| receives key material from the |DR|.
#. The |DR| becomes active after starting to respond to HBs and/or making progress 
   on the NACK messages.
#. The |DW| incorrectly does not report PUBLICATION_MATCHED_STATUS for a |DR|.

This problem will be fixed in release 6.0.1.

[RTI Issue ID SEC-1013]


.. _section-codegen-regressions:

RTI Code Generator
==================

.. _section-codegen-serialize-sample:

Invalid serialization of samples with types containing primitive members that require padding
----------------------------------------------------------------------------------------------

In 6.0.0, serialization of samples with a type containing a nested complex type with 
primitive members that require padding may fail. This means that a |DR| may 
receive an invalid value for a sample.

Example:

.. code-block:: text

    @nested struct Struct_3 {
        float m1;
        long long m2;
        short m3;
    };

    @nested struct Struct_2 {
        Struct_3 m1;
    };

    struct Struct_1 {
        Struct_2 m1;
    };

In this example, Struct_3 is nested and there is padding between m1 
(4-byte aligned) and m2 (8-byte aligned) of 4 bytes.

This problem affects the generated code for the following languages: C, C++, 
C++03, and C++11. It also affects DynamicData in all languages.

For generated code, a potential workaround for this problem is to generate 
code with a value of 1 for the ``-optimization``, but this may have performance 
implications.

This problem will be fixed in release 6.0.1.

[RTI Issue IDs CODEGENII-1196 and CORE-9777]



.. _section-codegen-serialize-java:

Java exception during serialization/deserialization of keyed types whose key is an unkeyed nested type with unbounded members 
-----------------------------------------------------------------------------------------------------------------------------

In 6.0.0, the keyhash max size calculation is wrong in Java when generating certain 
types using the *rtiddsgen* ``-unboundedSupport`` option. Specifically, this issue 
affects keyed types whose key is an unkeyed nested type with unbounded members. An 
example of that type is the following:

.. code-block:: text

    @nested
    struct MyNestedStruct {
        long myLong;
        string myString2;
    };

    struct MyStruct {
        MyNestedStruct myType; //@Key
    };

As a result of this problem, an application in Java using these kinds of types 
might throw an exception or produce a hang.

This problem will be fixed in release 6.0.1.

[RTI Issue ID CODEGENII-1194]


.. _section-codegen-1208:

Incorrect deserialization in .Net of samples from certain types when published from a writer with disable_inline_keyhash set to true
------------------------------------------------------------------------------------------------------------------------------------
In 6.0.0, the deserialization in .Net of a sample of a type that has inheritance, 
where the basetype has both keys and optional members, is incorrect if the sample 
is published by a |DW|, of any language, that has set the ``writer_qos.protocol.disable_inline_keyhash`` 
QoS to true.

An example of this type would be the following.

.. code-block:: text

    struct Shape1Final {
      @key 
      string<128> color;
      @optional 
      string<128> description;
      long shapesize;
    };

    struct Shape5Final : Shape1Final {
        double angle;
    };

As a result of this problem, the .Net subscriber might report an error like 
the following and not be able to deserialize the received sample:

.. code-block:: text

    PRESCstReaderCollator_serializedKeyOrSampleToKeyHash:!serialized sample to keyhash
    PRESCstReaderCollator_getSampleKeyHashes:!serialized key/sample to keyhash
    PRESCstReaderCollator_storeInlineQos:!get sample keyHashes
    PRESCstReaderCollator_storeSampleToEntry:!store inline qos in entry
    PRESCstReaderCollator_newData:!get entries

This problem will be fixed in release 6.0.1.

[RTI Issue ID CODEGENII-1208]


Generated code in traditional C++ with namespaces for an IDL containing a nested module called “rti” will not compile
---------------------------------------------------------------------------------------------------------------------

In 6.0.0, the generated code for traditional C++ does not compile if a module is called 
"rti" and the code is generated with ``-namespace``. For example:

.. code-block:: text

    module com {
        module rti {
            struct Foo {
                long m1;
            };
        };
    };

You will see errors like the following one:

.. code-block:: text

    FooDataPlugin.cxx: In function ‘RTIXCdrInterpreterPrograms*
    com::rti::media::generated::FooPlugin_get_programs()’:
    FooDataPlugin.cxx:882:33: error: ‘com::rti::xcdr’ has not been
    declared
                  	return rti::xcdr::get_cdr_serialization_programs<

If you experience this problem, contact RTI Support at support@rti.com. 

This problem will be fixed in release 6.0.1.

[RTI Issue ID CODEGENII-1099]



RTI Routing Service 
===================

.. _section-Product-Routing-xmlfail:

Create method in Service API fails to parse XML snippets that start with 'str://'
-------------------------------------------------------------------------------------

In 6.0.0, ``RTI::RoutingService::create_entity`` incorrectly fails if the XML snippet
string provided as an argument starts with the string URI ``str://``. Previously, 
``str://`` was expected/required for string URIs; now ``RTI::RoutingService::create_entity`` 
fails when ``str://`` is provided. 

This problem will be fixed in an upcoming patch.

[RTI Issue ID ROUTING-606]

.. _section-Product-Routing-logqos:

Executable ignores logging QoS
------------------------------

In 6.0.0, logging settings specified in the ``DomainParticipantFactory`` QoS are ignored 
when running the shipped |RS| application. (This problem does not occur when you 
deploy |RS| as a library linked into your application.) To work around this problem, 
set the logging format through the command line (using the ``-logFormat`` option) 
when using the shipped |RS| application.

This problem will be fixed in release 6.0.1.

[RTI Issue ID ROUTING-641]


.. _section-Product-Routing-DtdEntities:

User-defined DTD entities no longer supported
---------------------------------------------

In 6.0.0, user-defined entities within a |RS| configuration file are no longer processed,
and |RS| will generate a parsing error. For example, consider this XML configuration:

.. code-block:: xml

    <!DOCTYPE routing_service[

       <!ENTITY enabled "true">
    ]>
    <routing_service>
        <administration>
        <domain_id>0</domain_id>
        <distributed_logger>
            <enabled>&enabled;</enabled>
        </distributed_logger>
        </administration>
    </routing_service>

This example will cause an XSD validation error because the |RS| parser engine 
will not expand the DTD entity with its content.

Instead, you can use XML user variables in the form ``$(MY_VAR)``. For example,
consider the configuration below:

.. code-block:: xml

    <routing_service>
        <administration>
        <domain_id>0</domain_id>
        <distributed_logger>
            <enabled>$(ENABLED)</enabled>
        </distributed_logger>
        </administration>
    </routing_service>

The value of the variable ``ENABLED`` can be provided through an environment
variable of the same name, through the ``-DENABLED=<value>`` when
running with the shipped |RS| application, or through the
``ServiceProperty::user_envrionment`` when using the |RS| API.

[RTI Issue ID ROUTING-660]


.. _section-Product_Recording-Regress:

RTI Recording Service 
=====================

Legacy deserialized database table cannot be replayed or converted if it contains compact byte sequences or arrays
------------------------------------------------------------------------------------------------------------------
In 6.0.0, replaying or converting a legacy (version 5.3.1 or older) database stored in deserialized format 
fails if the database is recorded with octet/char sequences/arrays stored as blobs (that is, 
in compact mode). For example:

.. code-block:: text

    struct LargeByteSeqType {
      sequence<octet, 65530> large_byte_seq;
      ...;
    };

If the database stores ``large_byte_seq`` as a BLOB column, then *Replay* or *Converter* 
fails and complains with the following message:

.. code-block:: text

    exception:[DRT_DynamicType_expand_sequence_v3@3379]:Sequence length greater than built-in max

If you convert the legacy database so that it uses non-compact octet/char sequences/arrays, 
you may be able to work around this problem; however, non-compact octet/char sequences/arrays 
can also easily hit the column limit.

This issue will be fixed in release 6.0.1.

[RTI Issue ID RECORD-957]


Segmentation fault in *Replay Service* or *Converter* if recorded topics have "::" in their names
-------------------------------------------------------------------------------------------------
In 6.0.0, this issue occurs when a DDS topic contains "::" as part of its name. *Replay* or *Converter* 
will hit a segmentation fault when trying to process that topic's table. 

This issue will be fixed in release 6.0.1.

[RTI Issue ID RECORD-959]


.. _section-Product_CDS-Regress:

RTI Cloud Discovery Service 
===========================
In 6.0.0, the DomainParticipantFactory initialization didn't appear anywhere in the logging generated by 
*Cloud Discovery Service* for any verbosity level. *Cloud Discovery Service* printed the ROUTER build ID, 
but the "Welcome to NDDS" message, NDDS C, and NDDS Core Library build IDs weren't printed.

This issue will be fixed in release 6.0.1.

[RTI Issue ID CDS-51]