.. include:: /../getting_started/vars.rst
.. _section-General:
General Compatibility 6.0.0
***************************
This section describes compatibility issues that affect the *Connext* 6 suite.
It describes general, wire, and platform compatibility issues between *Connext*
6 and previous releases.
Unless noted otherwise, the issues in this section do not
apply to *RTI* |CONNEXT| *Micro*.
Platforms
=========
.. note::
For information on new and removed platforms in this release, see
:link_connext_whats_new_600:`What's New in 6.0.0 <>`.
See also individual products' :link_rti_community_doc_s:`Release Notes <600>`.
.. _section-General-Wire:
Wire Compatibility
==================
.. _section-General-RTPS:
RTPS Versions
-------------
The following table shows RTPS versions supported for each |CONNEXT| release.
In general, RTPS 2.1 and higher versions are interoperable, unless noted
otherwise. RTPS 2.0 and RTPS 1.2 are incompatible with current (4.2e
and later) versions of Connext DDS.
Although RTPS 2.1 and higher versions are generally interoperable, there may
be specific wire protocol interoperability issues between |CONNEXT| releases.
Wire protocol issues between *Connext* 6 and 5.3.1 are documented in this
section (:numref:`section-General-Wire`) for 6.0.0, in
:numref:`section-General-Wire-601` for 6.0.1, and in :numref:`section-General-Wire-610`
for 6.1.0; wire protocol issues between 5.3.1 and previous releases are documented
in the :link_release_notes_s:`5.3.1 Core Libraries Release Notes <5.3.1>`.
.. list-table:: RTPS Versions
:name: TableRTPSVersions
:widths: 80 20 20
:header-rows: 1
* - Connext DDS Release
- RTPS Standard Version [#f1]_
- RTPS Protocol Version [#f2]_
* - *Connext* 6
- 2.4 (partial support)
- 2.3
* - |CONNEXT| 5.2 and 5.3
- 2.2
- 2.2
* - |CONNEXT| 4.5f - 5.1
- 2.1
- 2.1
* - Data Distribution Service 4.2e - 4.5e
- 2.1
- 2.1
* - Data Distribution Service 4.2c
- 2.0
- 2.0
* - Data Distribution Service 4.2b and lower
- 1.2
- 1.2
.. rubric:: Footnotes
.. [#f1] Version number of the RTPS standards document, `OMG RTPS 2.3 specification `_
.. [#f2] RTPS wire protocol version number that |CONNEXT| announces in messages it puts on the wire
.. _section-General-GUID:
New default GUID generation mode
--------------------------------
Starting in 6.0.0, the default value of
``DDS::DomainParticipantQos::wire_protocol::rtps_auto_id_kind`` has changed from
``DDS_RTPS_AUTO_ID_FROM_IP`` (which caused the ``rtps_host_id`` to be the IP address by
default) to ``DDS_RTPS_AUTO_ID_FROM_UUID`` (which causes the ``rtps_host_id``,
``rtps_app_id``, and ``rtps_instance_id`` to be a
unique, randomly generated value). This change was done to comply with the latest
RTPS specification and reduce the possibility of non-unique GUIDs due to process
ID collision.
As a result of this change, out-of-the-box, |DPs| within the same process no longer
have a GUID that is ordered by creation time (via ``rtps_instance_id``). In other
words, you can no longer expect that all |DPs| will be ordered
sequentially within an application, since they are now using a random value to
determine the GUID rather than a sequential (time-based) value. This new ordering
may affect the usage of API functions that output a list of |DP|
InstanceHandles, such as ``DDS::DomainParticipant::get_discovered_participants``.
Furthermore, if you are using older versions of *RTI Administration Console*
and *RTI Monitor* to display data from a *Connext* 6 application, these tools may
display confusing
information if system properties (those that start with “dds.sys_info”) are
turned off. When you turn off system properties during discovery (to save on
bandwidth and discovery time), older versions of
*Admin Console* and *Monitor* figure out
what those properties are by assuming that part of the GUID is the host IP
address and process ID. (In some cases, *Admin Console* and *Monitor* can find the
IP address through the locators, but if that information is not available,
the tools will also assume that the random value is the
IP address.) For more information on how your older version of *Admin Console*
or *Monitor* handles host name and process ID, see the Help menu in
*Admin Console* for your specific version or see the *RTI Monitor User's
Manual* for your specific version.
(All older versions of *Admin Console* will have this issue with *Connext* 6 data,
out-of-the-box; not all older versions of *Monitor* will have this
issue out-of-the-box.)
If you want the default value to be ``DDS_RTPS_AUTO_ID_FROM_IP`` instead of
``DDS_RTPS_AUTO_ID_FROM_UUID``, like it was before, change it in the
``WIRE_PROTOCOL`` QosPolicy. (Remember that the old default value increases
the possibility of non-unique GUIDs due to process ID collision.)
Default shared memory locator has changed
-----------------------------------------
See information about this change in :numref:`section-General-Transport`.
.. _section-General-42e_alignment:
4.2e alignment option deprecated
--------------------------------
If your |CONNEXT| application’s data type uses a ``double``, ``long long``,
``unsigned long long``, or ``long double``, it will not interoperate with
applications built with *RTI Data Distribution Service* 4.2e or lower.
In previous releases (5.3.1 or lower), you could use the ``-use42eAlignment``
command-line option when generating code with *RTI Code Generator*, in combination
with the properties ``dds.data_writer.type_support.use_42e_alignment`` and
``dds.data_reader.type_support.use_42e_alignment``, to get backward compatibility.
These options are no longer available in *Connext* 6. The option
``use_42e_compatible_alignment`` in
``DynamicDataTypeSerializationProperty_t`` is not available either.
If you need interoperability between *Connext* 6 and 4.2e applications, contact
RTI Support at support@rti.com.
Changed wire representation of TypeObject
-----------------------------------------
See information about this change in :numref:`section-General-wire_rep_typeobject`.
TypeCode information is not sent by default
---------------------------------------------
See information about this change in :numref:`section-General-typecode_notsent`.
.. _section-General-Reliability:
Reliability Protocol
====================
.. _section-core-timeout:
Changes in behavior of write() operation with KEEP_LAST configuration
---------------------------------------------------------------------
In previous releases, a race condition may have caused the write operation on a
KEEP_LAST |DW| to return a timeout error when the send window was full and the
blocking time expired (according to ``max_blocking_time`` in the Reliability QosPolicy).
This race condition occurred only with small blocking times.
A keep-last reliable |DW| will block if the send window is full,
but it should not return a timeout error. In 6.0.0, this timeout problem has been
fixed (see RTI Issue ID CORE-8845 in the "Other Fixes" section of the
:link_release_notes_600:`Core Libraries Release Notes for 6.0.0<>`). If the blocking time expires,
the new sample is added to its associated instance. If there are ``depth`` samples
in the instance, the new sample replaces the oldest sample of the same instance,
even if that sample is not fully acknowledged.
For more details, see the
:link_connext_write_usersman:`"write() behavior with KEEP_LAST and KEEP_ALL" section in the RTI Connext DDS Core Libraries User's Manual <>`.
.. _section-General-Type-System:
Type System Compatibility
=========================
.. _section-General-Extended-CDR:
Migration to Extended CDR encoding version 2 (XCDR2)
----------------------------------------------------
Overview
^^^^^^^^
Starting in 6.0.0, |CONNEXT| supports the Extended Common Data Representation (CDR) encoding
version 2 (XCDR2), in addition to version 1 (XCDR). XCDR2 is supported in both
|CONNEXT| and |CONNEXT| *Micro*.
XCDR2 is more efficient on the wire than Extended CDR encoding version 1 (XCDR).
For new applications, Extended CDR encoding 2 is the recommended data
representation; however, if you need to keep compatibility and interoperability
with old |CONNEXT| applications (5.3.1 and below), you may have to continue
using Extended CDR encoding 1.
You may use the new ``DataRepresentationQosPolicy`` in the ``DataWriterQos`` to
configure which version of Extended CDR, version 1 or version 2, the |DW| will use
to serialize its data. The same QosPolicy exists in the ``DataReaderQos`` to
configure which version(s) the |DR| will accept from |DWs|.
|DWs| can offer only one data representation, while |DRs| can
request multiple data representations. The default value AUTO is translated into
XCDR.
|DRs| can be configured to receive data using both XCDR2 and XCDR. This
way, a |DR| can still interoperate and receive data from old |CONNEXT|
|DWs| using XCDR, while receiving data from new |DWs| using XCDR2.
The opposite is not true. |DWs| can publish only one data representation.
Therefore, if there is a requirement to receive data for a topic ‘T’ with old
|CONNEXT| |DRs|, you will have to continue to publish data for topic ‘T’
with XCDR representation on the new |DWs| or use a bridge such as *RTI Routing
Service* to translate between XCDR and XCDR2.
For additional information, see the
:link_connext_gsg_ext_types:`RTI Connext DDS Core Libraries Getting
Started Guide Addendum for Extensible Types <>`.
Known Issues
^^^^^^^^^^^^
Note the following known issues with XCDR2:
.. _section-codegen-keyhash:
Incorrect keyhash generation in .Net/Java when using XCDR2 data representation
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Incorrect key-hash generation in .Net when using XCDR2 data representation
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In 6.0.0, the generation of key-hashes in .Net is incorrect in some cases when
using the XCDR2 data representation.
As a result, a subscriber of a different language may treat as different
two instances that are actually the same if one of those two samples comes from
an application written in .Net and the other sample comes from an application
written in a different language.
The affected types are the following:
1) Keyed types where one of the key members is double long long or unsigned long long.
For example:
.. code-block:: text
struct MyStruct {
@key char m1;
@key double m2;
@key double m3;
long m4;
};
2) Keyed types that inherit from another type where the key fields are only
on the base type. For example:
.. code-block:: text
@nested
struct MyBaseStruct {
@key long myLong;
};
struct MyStruct: MyBaseStruct {
long myLong2;
};
In addition, when a publisher application in any language sets the
``writer_qos.protocol.disable_inline_keyhash`` QoS to true, and a different application
in C/C++/Java does not set this property, a .Net subscriber application can treat as
different two instances that are coming from each one of those applications in the
following cases:
1) Keyed types that have an inheritance relationship where the key can be in both
the parent or the derived class. For example:
.. code-block:: text
@nested
struct MyBaseStruct {
@key long myLong;
};
struct MyStruct: MyBaseStruct {
long myLong2;
};
2) Keyed types that have a key member whose type is the same as the one defined in
the previous point. For example:
.. code-block:: text
struct MyBaseStruct {
@key long myLong;
};
struct MyStruct: MyBaseStruct {
long myLong2;
};
struct MyKeyedType {
@key MyStruct m1
long m2;
}
3) Keyed types with a key member whose type is an unkeyed type that has an inheritance
relationship. For example:
.. code-block:: text
@nested
struct MyBaseStruct {
long myLong;
};
struct MyStruct: MyBaseStruct {
long myLong2;
};
struct MyKeyedType {
@key MyStruct m1
long m2;
}
These issues are fixed in release 6.0.1.
[RTI Issue IDs CODEGENII-1197 and CODEGENII-1198]
Incorrect key-hash generation in Java when using XCDR2 data representation
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In 6.0.0, the generation of key-hashes in Java is incorrect in some cases when
using the XCDR2 data representation.
As a result, a subscriber of a different language may treat as different two
instances that are actually the same when they come from an application written
in Java and an application written in a different language.
The types affected by this issue are keyed types that inherit from a base type,
when their keys are only in the base type. For example:
.. code-block:: text
@nested
struct MyBaseStruct {
@key long myLong;
};
struct MyStruct: MyBaseStruct {
long myLong2;
};
In addition, when a publisher application in any language sets the
``writer_qos.protocol.disable_inline_keyhash`` QoS to true, and a different application
in C/C++/.Net does not set this property, a Java subscriber application might interpret
as different two instances that are coming from each of the applications in the
following cases:
1) Keyed type that inherits from a base type and the key is only in the derived type:
.. code-block:: text
struct MyBaseStruct {
long myLong;
};
struct mystruct: MyBaseStruct {
@key long myLong2;
};
2) Keyed types who have a key member whose type is the same as the one defined in the
previous point. For example:
.. code-block:: text
struct MyBaseStruct {
long myLong;
};
struct MySruct: MyBaseStruct {
@key long myLong2;
};
struct MyKeyedType {
@key MyStruct m1
long m2;
};
These issues are fixed in release 6.0.1.
[RTI Issue IDs CODEGENII-1197 and CODEGENII-1198]
.. _section-codegen-serialize-xcdr2:
Incorrect serialization in Java when using XCDR2 for types containing wchar, double, long long, or unsigned long long members
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Serialization in Java when using the XCDR2 data representation for types
that contain wchar, double, long long, or unsigned long long members is
incorrect in 6.0.0.
As a result:
1) A Java publisher application publishing one of those types may
throw an error like the following one:
.. code-block:: text
com.rti.dds.cdr.IllegalCdrStateException: not enough available space in CDR buffer
2) A subscriber application in any language that receives data from that
Java publisher application might receive incorrect data or report
deserialization errors.
This problem is fixed in release 6.0.1.
[RTI Issue ID CODEGENII-1206]
.. _section-General-wire_rep_typeobject:
Changed wire representation of TypeObject
-----------------------------------------
In 6.0.0, |CONNEXT| enables *TypeObject* compression by default to reduce
bandwidth usage when exchanging endpoint discovery data. Specifically, |CONNEXT|
reduces the size needed to propagate a *TypeObject* as part of Simple Endpoint
Discovery. With this feature, a compressed version of the serialized *TypeObject*
(*TypeObjectLb*) is now sent as a Simple Endpoint Discovery parameter.
See :link_connext_whats_new_600:`What's New in 6.0.0 <>` for details.
As a result of this feature:
* Previous versions of |CONNEXT| will not be able to receive *TypeObject*
out-of-the-box from applications running *Connext* 6, since that *TypeObject*
is now compressed. |br|
* Therefore, out-of-the-box, type matching with |CONNEXT| 5.x applications
and lower will be done using the registered type name and not the
*TypeObject*. If the registered type names in the |DW| and |DR| are
different, *Connext* 6 and higher applications will not communicate
with |CONNEXT| 5.x and lower applications. |br|
When *Connext* 6 applications detect this scenario, the following warning will
be logged:
.. code-block:: text
DISCBuiltinTopicPublicationDataPlugin_deserialize:Received type information
for a remote Participant that does not support TypeObject compression.
TypeObject compression is currently enabled for the local participant,
which may prevent communication between local and remote Participant if
registered typenames are different. In order to avoid this issue, please
set DiscoveryConfigQosPolicy's endpoint_type_object_lb_serialization_threshold
to -1 to disable TypeObject compression.
* Additionally, |CONNEXT| 5.x services and tools relying on type definitions
require you to register the type through XML to properly work out-of-the-box
with 6.x. For example, if *Routing Service* 5.x communicates
with an out-of-the-box 6.x application, types will not be received through
discovery. Therefore, you need to configure the types in the
*Routing Service* configuration file (see the
:link_router_route_types:`Route Types section in the Routing Service User's Manual <>`).
Otherwise, *Routing Service* will not be able to create routes.
If your system is affected by any of the above issues, you have a few options:
* Don't send the compressed *TypeObject*. Set
``endpoint_type_object_lb_serialization_threshold`` in the *Connext* 6
application’s ``DISCOVERY_CONFIG`` QosPolicy to -1 for the |DP|.
Setting this field to -1 sends the old *TypeObject* instead of *TypeObjectLb*.
See the :link_discovery_config_usersman:`DDS_DiscoveryConfigQosPolicy table in the RTI Connext DDS Core Libraries User's Manual <>`.
|br|
|br|
If using XML configuration, you can use the following snippet within the
``participant_qos``:
.. code-block:: xml
-1
* If you experience only the type-matching issue but don't have
old services or tools, make the registered type names equal. For information
on how the type matching is done, see the :link_type_consistency_usersman:`"TypeConsistencyEnforcement QosPolicy" section in the RTI Connext DDS Core Libraries User's Manual <>`
or in the :link_connext_gsg_ext_types:`RTI Connext DDS Core Libraries Getting Started Guide Addendum for Extensible Types <>`. |br|
* If you experience the type issue only with old services or tools, update
the service's or tool's configuration file to load the type definition from XML.
.. _section-General-typecode_notsent:
TypeCode information is not sent by default
---------------------------------------------
In 6.0.0, the default value for ``DDS_DomainParticipantQos::resource_limits::
type_code_max_serialized_length`` has changed to 0 (from 2048). This change
disables sending *TypeCode* by default, in order to decrease Endpoint Discovery
traffic.
This change may affect compatibility with old |CONNEXT| (4.5f and below)
applications whose functionality depended on discovering the type information
from remote applications using *TypeCodes*. |CONNEXT| 4.5f and below did
not support *TypeObjects* (the standard alternative to *TypeCode*) as a way to
exchange type information; the only way to do that was through *TypeCodes*.
This change may also affect compatibility with old versions of *RTI Routing Service*
(4.5f and below) if you did not provide the type definitions to *Routing
Service* using XML. In this case, some routes in the old *Routing Service*
may stop forwarding data.
If you have this problem with |CONNEXT| 4.5f and below, configure your
*Connext* 6 application to send *TypeCodes* by setting
``DDS_DomainParticipantQos::resource_limits::
type_code_max_serialized_length`` to the old default value (2048) or a
bigger value if your types need it.
.. _section-General-Unbounded:
Unbounded sequences and strings in XML type representation
----------------------------------------------------------
Previously, if a type defined in XML had its sequences or strings set to -1
in the attributes ``sequenceMaxLength`` or ``stringMaxLength``, the resulting
sequence or string length was interpreted as being of a default bounded
size rather than unbounded. The default size for sequences was 100 and
for strings was 255. This problem has been resolved. The resulting length
is now interpreted as unbounded in *Connext* 6.
This change may lead to some unexpected memory growth when moving existing
applications to *Connext* 6.
If the strings and/or sequences are not supposed to be unbounded, set the
maximum length to 100 for sequences and 255 for strings.
If the strings or sequences are supposed to be unbounded, make sure that
you limit the memory usage by using properties such as
``dds.data_writer.history.memory_manager.fast_pool.pool_buffer_max_size`` or
the ```` tag in *RTI Routing Service*, *RTI Recording Service*,
and *XML-Based Application Creation*. For additional information, see the
:link_instanceman_usersman:`“DDS Sample-Data and Instance-Data Memory Management” chapter in the
RTI Connext DDS Core Libraries User’s Manual <>`.
.. _section-General-wchar_wstring:
wchar and wstring language binding changes
------------------------------------------
Starting in |CONNEXT| 6.0.0 (and |CONNEXT| *Micro* 3.0.0), for C, traditional C++,
and Ada languages, the mapping of an IDL wchar has changed from a 4-byte
integer to a 2-byte integer. ``DDS_Wchar`` is now mapped to ``DDS_UnsignedShort``
instead of ``DDS_UnsignedLong``. This change may lead to some compilation warnings
when compiling old |CONNEXT| applications with libraries in *Connext* 6
(and |CONNEXT| *Micro* 3.0.0) and higher. If so, you will need to fix these
compilation warnings.
Wire interoperability with |CONNEXT| 5.x and lower (and |CONNEXT| *Micro* 2.4.x and lower)
is not broken as long as you continue using the Extended CDR encoding version
1 data representation (see the :link_datarep_ext_types:`Data Representation chapter in the
RTI Connext DDS Core Libraries Getting Started Guide Addendum for
Extensible Types <>`), because the wire representation of a wchar and wstring
is still the same.
.. |tc.ignore_mem| replace:: dds.type_consistency.ignore_member_names
.. |tc.ignore_seq| replace:: dds.type_consistency.ignore_sequence_bounds
Properties |tc.ignore_mem| and |tc.ignore_seq| have been deprecated
-------------------------------------------------------------------
See information about this change in :numref:`section-Product-Core-Ignore_Properties`.
.. _section-General-Transport:
Transport Compatibility
=======================
.. _section-General-shmem-locator:
Default shared memory locator has changed
-----------------------------------------
*Connext* 6 changes the way |CONNEXT| detects if two different |DPs|
can communicate over shared memory. In previous releases, the compatibility
detection was based on both |DPs| having the same shared memory
locator. In this release, the compatibility detection is based on checking
if it is possible to attach to a shared memory segment compatible with
|CONNEXT|. See “Improved shared memory transport compatibility detection”
in :link_connext_whats_new_600:`What's New in 6.0.0 <>`
for more information.
As a result of this change, *Connext* 6 applications will not communicate
over shared memory with older |CONNEXT| applications. You will need to take
the following action, depending on what release you’re communicating with.
To communicate over shared memory with |CONNEXT| 5.3:
* Configure the ``WIRE_PROTOCOL`` QoS: In |CONNEXT| 5.3 and |CONNEXT| 6,
set the ``rtps_host_id`` field to ``DDS_RTPS_AUTO_ID`` in all the
|DPs| running on the same host. In |CONNEXT| 6
|DPs|, set the ``rtps_auto_id_kind`` field to the same value
used in the |CONNEXT| 5.3 application. If the |CONNEXT| 5.3
|DPs| are using an ``rtps_auto_id_kind`` field of
``DDS_RTPS_AUTO_ID_FROM_UUID``, it is also required to set the
``dds.transport.shmem.builtin.use_530_from_uuid_locator`` property to TRUE
for all the |CONNEXT| 6 |DPs|. (By default, it is set to
FALSE.)
* If the ``rtps_host_id`` field cannot be set to ``DDS_RTPS_AUTO_ID`` due to
system restrictions, set the ``dds.transport.shmem.builtin.host_id`` property
to the same value for all the |DPs| running on the same host.
(That is, each |DP| has to have the property set to the same
value.)
To communicate over shared memory with |CONNEXT| 5.2 or older versions:
* Configure the ``WIRE_PROTOCOL`` QoS: In |CONNEXT| 5.2 or older versions,
set the ``rtps_host_id`` field to ``DDS_RTPS_AUTO_ID`` in all the
|DPs| running on the same host. In |CONNEXT| 6
|DPs|, set the ``rtps_auto_id_kind`` field to
``DDS_RTPS_AUTO_ID_FROM_IP``.
* Another option, available only if the ``WIRE_PROTOCOL`` QoS’s ``rtps_host_id``
(in |CONNEXT| 5.2 or older) is set to a value different than
``DDS_RTPS_AUTO_ID``: define the ``dds.transport.shmem.builtin.host_id`` property
in |CONNEXT| 6 |DPs| with the same value as ``rtps_host_id``
in the ``WIRE_PROTOCOL`` QoS of the older version.
.. _section-General-vxworks:
VxWorks shared-memory transport compatibility
---------------------------------------------
Previously, applications could not communicate between kernel and RTP mode
using the shared memory transport on 64-bit VxWorks® 6 systems. (This is not
an issue for 64-bit VxWorks 7 systems.) This issue has been resolved in 6.0.0.
As a result of this fix, applications built with older |CONNEXT| releases
cannot communicate with applications built with this release if the
communication uses shared memory on 64-bit VxWorks 6 systems and occurs
between kernel and RTP mode. (This configuration is not a common use case.)
.. _section-General-XML:
XML Compatibility
=================
.. _section-General-qos-comp:
QoS Profile multiple inheritance
--------------------------------
QoS Profile composition (also referred to as QoS Profile multiple inheritance) is
an enhancement to the existing QoS Profile single inheritance mechanism, allowing
a QoS Profile to be composed from multiple QoS Profiles. See the section
:link_connext_inherit_usersman:`"QoS Profile Inheritance and Composition" in the RTI Connext DDS Core Libraries User's Manual <>`
for new recommendations in *Connext* 6. Following these recommendations is strongly
encouraged to avoid unexpected results.
XSD issues
----------
See XSD-related regressions in :numref:`section-xml-compatibility`.
Other Compatibility Issues
==========================
Behavior change when retrieving QoS using topic_name (when there are multiple matching QoSes)
---------------------------------------------------------------------------------------------
When you have multiple matching QoSes of the same type (e.g., ``datawriter_qos``),
because either a ``topic_filter`` attribute is not provided or it is
provided with “*”, the new behavior in *Connext* 6 is for |CONNEXT| to return the
**first** matching QoS. Previously, |CONNEXT| returned the **last** matching
QoS.
For example, you could use a |CONNEXT| API that returns a QoS based on a
specified ``topic_name`` value. In the C API, you could use a function like
``DDS::DomainParticipantFactory::get_datawriter_qos_from_profile_w_topic_name()``
to return a QoS based on a topic name.
Consider the following XML snippet:
.. code-block:: xml
...
...
...
...
...
Say that the above is your XML file, and you specify the ``topic_name`` “MyTopic”.
Neither A nor B matches “MyTopic”, so |CONNEXT| has to choose one of the
other QoSes (C, D, or E). Since C, D, and E have no specified ``topic_filter``,
any of them could be used as a matching candidate for “MyTopic”. Before
6.0.0, the API would have returned the “E” QoS, because E is the **last**
matching QoS. This behavior has changed. Convention dictates that the **first**
matching candidate should be used, not the last. Therefore, if there is no
QoS that matches the ``topic_name``, |CONNEXT| now gets the **first** candidate
QoS value with ``topic_filter`` unspecified—in this case, C instead of E.
Now consider the following XML snippet:
.. code-block:: xml
...
...
...
...
...
Say that the above is your XML file, and you don’t specify a ``topic_name``.
|CONNEXT| cannot find a QoS in this file with an unspecified ``topic_filter``;
however, it can match with one of the “*” ``topic_filter`` attributes—but there
are multiple such QoSes. Before 6.0.0, |CONNEXT| returned the “E” Qos
(the **last** matching candidate value). Now, in 6.0.0 forward, |CONNEXT| returns the
**first** candidate value, C.
As a result of this change in *Connext* 6, you may see a different QoS returned
than before, but only in cases where there are multiple matching QoSes to
choose from. If you want the same behavior in *Connext* 6 as before, change the
order of the QoSes in your XML file. For instance, in the above examples,
switch the C ```` with the E ````.