.. include:: /../getting_started/vars.rst
.. _section-Product-Core-610:
RTI Connext Core Libraries
**************************
The following issues affect backward compatibility in the Core Libraries
starting in Release 6.1.0. Issues in the Core Libraries may affect components
that use these libraries, including services and tools.
Configuration Changes
=====================
.. _CORE-9387:
Property name typos are now errors, not warnings
------------------------------------------------
|CONNEXT| 6.1.0 provides out-of-the-box stricter property validation than
earlier releases. In the following XML configuration, the property
``ignore_sequence_bounds`` contains a typo:
.. code-block:: xml
:emphasize-lines: 9
dds.type_consistnecy.ignore_sequence_bounds
true
Previously, in 6.0.1, a typo in the name of a property within a well-known namespace
was reported out-of-the-box as a warning, the property was ignored, and the
creation of the entity was successful. For the example above, in 6.0.1 you would see
the following:
.. code-block:: text
[D0000|Sub(80000009)|T=Example MyType|CREATE Reader]
DDS_PropertyQosPolicy_validatePropertyNames:Unexpected property:
dds.type_consistnecy.ignore_sequence_bounds. Closest valid property:
dds.type_consistency.ignore_sequence_bounds
In 6.1.0, a typo in the name of a property within a well-known namespace
is reported out-of-the-box as an error and the creation of the entity fails.
For the example above, you will see the following:
.. code-block:: text
[0x0101C928,0x1845FBA5,0xE53A39B9:0x80000009{E=Su,D=0}|CREATE DR WITH TOPIC Example MyType]
DDS_PropertyQosPolicy_validateEntityPropertyNames:Unexpected property:
dds.type_consistnecy.ignore_sequence_bounds. Closest valid property:
dds.type_consistency.ignore_sequence_bounds. If you wish to proceed with
this property name anyway, change
'dds.participant.property_validation_action' to 'VALIDATION_ACTION_SKIP' or
'VALIDATION_ACTION_WARNING'.
[0x0101C928,0x1845FBA5,0xE53A39B9:0x80000009{E=Su,D=0}|CREATE DR WITH TOPIC Example MyType]
DDS_DataReaderQos_is_consistentI:inconsistent QoS property
[0x0101C928,0x1845FBA5,0xE53A39B9:0x80000009{E=Su,D=0}|CREATE DR WITH TOPIC Example MyType]
DDS_Subscriber_create_datareader_disabledI:ERROR: Inconsistent QoS
You can go back to the 6.0.1 behavior where the typo is reported as a warning
by setting the property ``dds.participant.property_validation_action`` to
VALIDATION_ACTION_WARNING.
You can also go back to the 6.0.0 behavior where validation was skipped
by setting the ``dds.participant.property_validation_action`` to
VALIDATION_ACTION_SKIP.
The property ``dds.participant.property_validation_action`` accepts the
following values:
- **VALIDATION_ACTION_EXCEPTION:** Validate properties. Upon failure, log
errors and fail.
- **VALIDATION_ACTION_WARNING:** Validate properties. Upon failure, log warnings
and do not fail.
- **VALIDATION_ACTION_EXCEPTION:** Skip validation.
See :link_propqos_usersman_610:`PROPERTY QosPolicy, in the RTI Connext Core Libraries User's Manual <>`
for more information.
.. CORE-9387
.. default value change also mentioned in "Changes to Defaults" in What's New.
Error reported if load_plugin property not specified in properties of external plugin
-------------------------------------------------------------------------------------
|CONNEXT| 6.1.0 will report an error when parsing the properties of an external
plugin (e.g., *RTI Security Plugins*) if the ``load_plugin`` property for the
plugin is not defined. Consider the following example configuration for the
*Security Plugins*:
.. code-block:: xml
:emphasize-lines: 9
com.rti.serv.secure.create_function
RTI_Security_PluginSuite_create
Even though the ``com.rti.serv.secure.create_function`` property is legal and
it does not contain typos, in 6.1.0, you will see the following error
when running with the above configuration, because the property
``com.rti.serv.load_plugin`` is not defined:
.. code-block:: text
DDS_PropertyQosPolicy_validateEntityPropertyNames:Unexpected property:
com.rti.serv.secure.create_function. Closest valid property:
rti.monitor.create_function. If you wish to proceed with this property name
anyway, change 'dds.participant.property_validation_action' to
'VALIDATION_ACTION_SKIP' or 'VALIDATION_ACTION_WARNING'.
DDS_DomainParticipantQos_is_consistentI:inconsistent QoS property
DDS_DomainParticipantFactory_set_default_participant_qosI:ERROR: Inconsistent QoS
DDS_DomainParticipantFactory_load_profilesI:!set default DomainParticipant Qos
DDS_DomainParticipantFactory_create_participant_disabledI:ERROR: loading profiles
To fix the problem, make sure that the ``load_plugin`` property for the plugin
is defined:
.. code-block:: xml
:emphasize-lines: 9
com.rti.serv.load_plugin
com.rti.serv.secure
com.rti.serv.secure.create_function
RTI_Security_PluginSuite_create
.. CORE-9387
.. _section-Product-configuration-autodispose_unregistered_instances:
Instances no longer disposed by default when unregistered
---------------------------------------------------------
The default value of **autodispose_unregistered_instances** in the
:link_writerdatalife_usersman_610:`WRITER_DATA_LIFECYCLE QoS Policy <>`
has changed from TRUE to FALSE. As a result,
instances are no longer disposed by default when they are unregistered.
Disposing an instance and unregistering from an instance are two distinct
actions that a |DW| can take. Therefore, in the majority of use cases, it is
better and more transparent to explicitly perform each action when appropriate
in your application rather than relying on |CONNEXT| to perform either action
automatically.
If the new default of FALSE does not work for your application, set it to TRUE.
In addition, the **autodispose_unregistered_instances** setting no longer
applies to a |DW| deletion. See
:numref:`section-Product-other-autodispose_unregistered_instances` for
details.
.. CORE-7485
Inconsistent QoS error when setting availability.enable_required_subscriptions to TRUE and history kind to KEEP_LAST on |DW|
----------------------------------------------------------------------------------------------------------------------------
Setting ``enable_required_subscriptions`` in the
:link_availability_usersman_610:`AVAILABILITY QoS Policy <>` now
requires a history **kind** of KEEP_ALL. The reason is that not all samples
can be guaranteed to be delivered to the required |DRs| if history **kind** is
KEEP_LAST.
.. CORE-9855
TYPE_CONSISTENCY_ENFORCEMENT QoS Policy has more permissive default values for ignore_sequence_bounds and ignore_string_bounds
------------------------------------------------------------------------------------------------------------------------------
The :link_type_consistency610_usersman:`TYPE_CONSISTENCY_ENFORCEMENT QoS Policy <>`
has new default values for two of
its boolean members: **ignore_sequence_bounds** and **ignore_string_bounds**.
To comply with the `OMG 'Extensible and Dynamic Topic Types for DDS' specification, version 1.3 `_,
the default values have changed from FALSE to TRUE.
As a result of this change, out of the box in 6.1.0, a |DW| publishing a *Topic*
with a type that contains a sequence member with a maximum bound 'A' will match
with a |DR| subscribing to the same *Topic* using a type where the same sequence
member has a smaller maximum bound.
Samples received by the |DR| will fail to be deserialized and be dropped if the
number of elements in the sequence is larger than the maximum allowed by the |DR|
type.
For example:
.. code-block:: c
struct MyType1 {
sequence m1;
}
struct MyType2 {
sequence m1;
}
In earlier releases, a |DW| publishing **MyType1** and a |DR| subscribing to
**MyType2** did not match out of the box. In 6.1.0, the entities match.
However, if the |DR| receives a sample where **m1** has 8 elements, it will log a
deserialization error and the sample will be reported as lost with the reason
DDS_LOST_BY_DESERIALIZATION_FAILURE.
.. CORE-9338
Removed refilter field in HISTORY QoS Policy
--------------------------------------------
The ``refilter`` field in the HISTORY QoS Policy has been removed along with the
associated public enum DDS_RefilterQosPolicyKind. If you are using this QoS
setting, you will need to remove it from any source code and XML configuration
files, and recompile your application.
The filtering behavior of a |DW| can now only be controlled through
the ``max_remote_reader_filters`` field in the DATA_WRITER_RESOURCE_LIMITS QoS
Policy. The behavior of ``max_remote_reader_filters`` has not changed.
.. CORE-5544
Deprecated transport.use_510_compatible_locator_kinds
-----------------------------------------------------
The ``use_510_compatible_locator_kinds`` transport property was used to communicate
over shared memory or UDPv6 between |CONNEXT| 5.2.0 (or later) and a previous
release.
This property is deprecated in |CONNEXT| 6.1.0. Even though it is still
supported, the new ``minimum_compatibility_version`` property is recommended. Set
the value of ``minimum_compatibility_version`` to ``5.1.0`` to indicate that the transport
should be compatible with |CONNEXT| 5.1.0.
.. GREEN-1861
.. _section-Product-api-compatibility:
API Changes
===========
The following Application Program Interfaces (APIs) have been changed or
deprecated in 6.1.0. For new APIs, see :link_connext_whats_new_610:`What's New in 6.1.0 <>`.
See also :numref:`section-Product-Codegen-610` for *Code Generator* related
changes.
.. _section-Product-api-csharp:
Migrating to the new C# API
---------------------------
This release includes a new .NET Standard 2.0-compatible C# language binding
(see :link_connext_csharp_whats_new_610:`Build applications for .NET 5 using new modern, multi-platform C# language binding, in What's New in 6.1.0 <>`),
which will replace the previous binding. The new C# binding has to be installed
with an additional ``.rtipkg`` file.
The old binding is deprecated and will be removed in the next major release.
You should write new .NET components in your system using the new binding
and consider migrating existing components. The old binding will still receive
updates for critical issues, but won't include new features or improvements.
The new binding has a few limitations in this first release, explained in the
`release notes `__.
Advantages of the new binding
"""""""""""""""""""""""""""""
The new C# binding offers a number of advantages with respect to the old one:
- It is multi-platform (the old binding runs only on Windows®).
- It runs on .NET 5 and other .NET Standard 2.0-compatible systems, not just .NET Framework.
- It provides a modern and idiomatic C# API that uses common C# interfaces, patterns,
and conventions.
- It no longer requires compiling user types in C++/CLI; both the API and the generated
code are C#.
- The type and method documentation is included in the assembly and visible with IntelliSense.
- It is distributed as a NuGet package, making it easier to use and deploy.
The NuGet package transparently manages the native dependencies for the right target.
Migrating to the new binding
""""""""""""""""""""""""""""
If you're planning to move your .NET Framework applications to .NET 5, you will
need to migrate to the new |CONNEXT| C# binding. The old one runs only on
.NET Framework.
Even if you plan to continue using .NET Framework for now, you can start the migration.
The new binding also supports .NET Framework 4.6.1-4.8, and both bindings
can coexist within the same .NET assembly, so you can port your applications
incrementally (you can't, however, pass objects created by one API to methods of
the other one). Like any other DDS application, applications using either binding
will interoperate on the wire.
To start using the new binding in an existing code base, add the
``Rti.ConnextDds`` NuGet package to your ``.csproj`` files.
.. code-block:: bash
> dotnet add package Rti.ConnextDds
By default, the package is downloaded from nuget.org. This package requires
a license to run your applications. To use the package from your |CONNEXT|
installation, run the following command before ``dotnet add``:
.. code-block:: bash
> dotnet nuget add source /lib/dotnet -n RTI
.. note::
After installing the .NET package, the *RTI Launcher* GUI will not be able
to generate code for the C# Language option. Use the *rtiddsgen* command-line
option ``-language C#`` instead.
Tips for users of the old binding
"""""""""""""""""""""""""""""""""
There are a few key differences in the way you write your applications using the
new and the old bindings. (This section is also helpful if you are familiar
with the |CONNEXT| Java binding, which is similar to the old C# binding.)
- **Error reporting.** The new binding reports errors exclusively as exceptions.
In the old binding, some methods may report an error in the creation of some
objects by returning ``null``.
..
-
**Object lifecycle.** Both bindings use the factory pattern for ``Entity``-derived
objects. However, the way they are deleted is different:
In the old binding, the factory type provided a ``delete_*`` method as well as
a ``delete_contained_entities`` method when necessary:
.. code-block:: C#
:caption: Object lifecycle in the old binding
:emphasize-lines: 5-6
DomainParticipant participant = DomainParticipantFactory.get_instance().create_participant(0, ...);
// ...
Topic topic = participant.create_topic("HelloWorld", ...);
// ...
participant.delete_contained_entities();
DomainParticipantFactory.get_instance().delete_participant(participant);
In the new binding, types that can be explicitly deleted implement ``IDisposable``,
and their `Dispose()` method automatically deletes the contained entities if needed.
.. code-block:: C#
:caption: Object lifecycle in the new binding (explicit Dispose call)
:emphasize-lines: 5
DomainParticipant participant = DomainParticipantFactory.Instance.CreateParticipant(0);
// ...
Topic topic = participant.CreateTopic("HelloWorld");
// ...
participant.Dispose();
.. code-block:: C#
:caption: Object lifecycle in the new binding (using block)
:emphasize-lines: 1
using DomainParticipant participant = DomainParticipantFactory.Instance.CreateParticipant(0);
// ...
Topic topic = participant.CreateTopic("HelloWorld");
// participant.Dispose() called when scope ends
..
-
**Generic programming.** The new binding uses generic classes. For example, in
the new binding, a ``DataReader`` for the type `Foo` is ``DataReader``.
In the old binding, this type was generated and called `FooDataReader`.
..
-
**Type registration.** The new binding registers data types automatically
upon the creation of a ``Topic``. The old binding required a explicit call
to ``FooTypeSupport.register_type(participant, typeName)``.
..
-
**Status updates (listeners).** The new API defines C# events for each ``Entity``
to notify of updates to each status. The old API provided listener interfaces
that had to be implemented and attached to the Entity.
This example compares how to handle two |DW| statuses using each binding.
.. code-block:: C#
:caption: Handling status updates with a listener in the old API
class MyWriterListener : DataWriterListener
{
public override void on_publication_matched(DataWriter writer, ref PublicationMatchedStatus status)
{
// handle PublicationMatchedStatus update
}
public void on_offered_deadline_missed(DataWriter writer, ref OfferedDeadlineMissedStatus status)
{
// handle OfferedDeadlineMissedStatus update
}
}
// ...
var writer = publisher.create_datawriter(
topic,
Publisher.DATAWRITER_QOS_DEFAULT,
null,
StatusKind.STATUS_MASK_NONE);
var listener = new MyWriterListener();
writer.set_listener(
listener,
StatusKind.PUBLICATION_MATCHED_STATUS | StatusKind.OFFERED_DEADLINE_MISSED_STATUS);
In the new API, the entity contains an event for each status that can receive
updates:
.. code-block:: C#
:caption: Handling status updates with event handlers in the new API
var writer = publisher.CreateDataWriter(topic);
writer.PublicationMatched += (writer, status) =>
{
// handle PublicationMatchedStatus update
};
writer.OfferedDeadlineMissed += (writer, status) =>
{
// handle OfferedDeadlineMissedStatus update
};
The old API allows setting the listener in the constructor.
In the new API, the constructor receives a ``preEnableAction`` argument that
allows performing an action on the entity being created right before it is
enabled. This can be used to set the event handlers.
.. code-block:: C#
:caption: Handling status updates with an event handler in the new API (in constructor)
var writer = publisher.CreateDataWriter(
topic,
preEnableAction: writer =>
{
writer.PublicationMatched += OnPublicationMatched;
writer.OfferedDeadlineMissed += OnOfferedDeadlineMissed;
});
..
-
**Reading data.** The methods for reading data are significantly different.
Compare the following code in the old API with the code in the new API that
follows.
.. code-block:: C#
:caption: Reading all available data using the old API
FooSeq data_seq = new FooSeq();
SampleInfoSeq info_seq = new SampleInfoSeq();
try
{
reader.read( // or .take(
sampleSeq,
infoSeq,
ResourceLimitsQosPolicy::LENGTH_UNLIMITED,
SampleStateKind::ANY_SAMPLE_STATE,
ViewStateKind::ANY_VIEW_STATE,
InstanceStateKind::ANY_INSTANCE_STATE);
for (int i = 0; i < sampleSeq.length; i++)
{
SampleInfo info = info_seq.get_at(i);
if (!info.valid_data)
{
Foo data = data_seq.get_at(i);
// use data
}
}
reader.return_loan(sampleSeq, infoSeq);
}
catch(Retcode_NoData)
{
}
In the new API, a single, ``IDisposable`` and ``IEnumerable`` collection
provides the data and the info. When no data is available, the reader returns
an empty collection instead of throwing an exception. In both bindings, the data
is loaned. In the new binding, the loan is returned with ``Dispose()``
(here called automatically at the end of the scope of the ``using`` block),
instead of ``return_loan()``.
.. code-block:: C#
:caption: Reading all available data using the new API
using (LoanedSamples samples = reader.Read()) // or .Take()
{
foreach (LoanedSample sample in samples)
{
if (sample.Info.ValidData)
{
Foo data = sample.Data;
// use data
}
}
}
When the ``SampleInfo`` is not relevant, the code can be simplified further:
.. code-block:: C#
:caption: Reading all available data using the new API (ignoring the SampleInfo)
:emphasize-lines: 3
using (LoanedSamples samples = reader.Read()) // or .Take()
{
foreach (Foo data in samples.ValidData())
{
// use data
}
}
To copy the data, the generated data types provide a constructor,
``new Foo(data)``.
In the new API, ``Read()`` and ``Take()`` receive no arguments. The method
``Select()`` allows specifying all the optional arguments. ``Select()``
replaces all the other variations of ``read`` and ``take`` in the old API.
For example, instead of ``reader.take_w_condition(...)``, use
``reader.Select().WithCondition(...).Take()``.
The new API also provides a new method, ``reader.TakeAsync()``. This methods
returns an ``IAsyncEnumerable`` that provides the data asynchronously as it
is received.
For more examples, in the `API Reference `__,
under *Modules > Programming Snippets*, select *Subscription Examples* and
*IDL examples*.
|br| |br|
-
**Managing XML profiles.** In the new binding, XML-defined QoS profiles, types,
and applications are managed by the ``QosProvider`` class, instead of the
``DomainParticipantFactory``.
The ``QosProvider`` should also be used to create entities with an XML QoS profile.
.. code-block:: C#
:caption: Creating a |DW| with an XML profile with the old API
var writer = publisher.create_datawriter_with_profile(
topic,
"MyQosLibrary",
"MyQosProfile",
null,
StatusMask.STATUS_MASK_NONE);
In the new API, you can use ``QosProvider.Default``:
.. code-block:: C#
:caption: Creating a |DW| with an XML profile with the new API (default provider)
var writerQos = QosProvider.Default.GetDataWriterQos("MyQosLibrary::MyQosProfile");
var writer = publisher.CreateDataWriter(topic, writerQos);
To configure which profiles are loaded by default, instead of
using ``DomainParticipantFactoryQos.profile``, use ``QosProvider.SetDefaultProviderParams()``.
Or create a new ``QosProvider`` to load a specific file:
.. code-block:: C#
:caption: Creating a |DW| with an XML profile with the new API (custom provider)
var qosProvider = new QosProvider("my_profiles.xml");
var writerQos = qosProvider.GetDataWriterQos("MyQosLibrary::MyQosProfile");
var writer = publisher.CreateDataWriter(topic, writerQos);
..
-
**Immutable types.** Some types in the new API are immutable and implement
a "non-destructive mutation" pattern. All QoS types follow this pattern.
This makes the syntax to configure a QoS policy quite different. Compare
the code required to create a |DR| with two QoS policies using
the old and the new binding.
.. code-block:: C#
:caption: Configure QoS policies with the old binding
var readerQos = new DataReaderQos();
subscriber.get_default_datareader_qos(readerQos);
readerQos.reliability.kind = ReliabilityQosPolicyKind.RELIABLE_RELIABILITY_QOS;
readerQos.history.kind = HistoryQosPolicyKind.KEEP_LAST_HISTORY_QOS;
readerQos.history.depth = 10;
reader = subscriber.create_datareader(topic, readerQos, null, StatusMask.STATUS_MASK_NONE);
In the new binding, each "edit" to a QoS object creates a
new object that contains the values of the original object plus the edits.
.. code-block:: C#
:caption: Configure QoS policies with the new binding
var readerQos = subscriber.DefaultDataReaderQos
.WithReliability(policy => policy.Kind = ReliabilityKind.Reliable)
.WithHistory(policy =>
{
policy.Kind = HistoryKind.KeepLast;
policy.Depth = 10;
});
var reader = subscriber.CreateDataReader(topic, readerQos);
..
-
**Use of properties instead of getters or setters.** The new binding prefers
C# properties over getter/setter methods in most cases. You may find that a
method in the old API (such as ``subscriber.get/set_default_datareader_qos()``)
is a property in the new API (``subscriber.DefaultDataReaderQos``)
For more information, see the `API Reference `__,
under *Modules > Programming Snippets > Entity Examples*.
Warning for C++/CLI language option
-----------------------------------
This release includes a new C# language binding for .NET Standard 2.0 ,
which will replace the previous binding. The new C# binding has to be installed
with an additional ``.rtipkg`` file. (See :numref:`section-Product-api-csharp`.)
Using the ``-language C#`` option without the additional package will
continue to generate code for the old API, but will print a warning that
the old binding will be removed in a future release.
When you install the new package, ``-language C#`` will stop printing the
warning and use the new binding. (``-language C++/CLI`` produces the same
warning, but is not supported in the new API.)
.. CODEGENII-1464
Changes to SHMEM Transport APIs
-------------------------------
The signature of the API that creates a new SHMEM transport instance in C
has changed. It includes a new parameter called ``minimum_compatibility_version``.
.. code-block:: C++
NDDS_Transport_Plugin* NDDS_Transport_Shmem_create(
NDDS_Transport_Address_t *default_network_address_out,
const struct DDS_PropertyQosPolicy *property_in,
const struct DDS_ProductVersion_t *minimum_compatibility_version);
If you were calling **NDDS_Transport_Shmem_create** before, you must modify the
function call to migrate your applications to 6.1.0. You must now add a third
parameter, the ``minimum_compatibility_version``.
The created shared memory transport plugin will be compatible with the |CONNEXT|
version given in this parameter. Provide ``NULL`` as the argument to impose no
compatibility restrictions. Doing so achieves the same behavior as in 6.0.0 and
6.0.1, where ``NDDS_Transport_Shmem_create`` did not have the
``minimum_compatibility_version`` parameter. To be compatible with releases earlier
than 6.0.0, set the field to the version of the release that you want to be
compatible with.
``minimum_compatibility_version`` was added to support a new feature that allows
capturing network traffic into a pcap file from a |DP|. For more information on
the new network capture feature in this release,
see :link_netcapt_usersman_610:`Network Capture in the RTI Connext Core Libraries User's Manual <>`.
.. CORE-10803
Modern C++ API: Constructor and listener setters behave as they used to, but you should use new APIs
----------------------------------------------------------------------------------------------------
Starting in this release, entities expect their listeners to be passed as a
``std::shared_ptr``. Previously, listeners were expected as raw pointers.
Example of the new API:
.. code-block:: C++
class MyReaderListener : public dds::sub::DataReaderListener {
// …
} ;
// …
auto my_listener = std::make_shared();
dds::sub::DataReader reader(subscriber, topic, qos, my_listener);
This change simplifies the lifecycle of the listener and its entity. Previously,
an entity with a listener was “retained” (it wouldn’t be automatically destroyed
even if its reference count reached zero) to allow for the application to unset
the listener and delete it.
Now an Entity with a listener holds a reference to the ``shared_ptr``, keeping
the listener alive while the Entity is alive. If the Entity reference count
reaches zero, it is destroyed even if it has a listener.
The following APIs have changed:
- Entity constructors now take a ``shared_ptr`` to the listener. Constructors
taking a raw pointer are deprecated and may be removed in a future version.
..
- New functions in each Entity called ``set_listener`` and ``get_listener``
have been added. They receive and return a ``shared_ptr`` to the listener.
The previous functions that received and returned a raw pointer are deprecated
and may be removed in a future version.
..
- The ``rti::core::ListenerBinder`` utility is deprecated because it is no longer
needed and may be removed in a future version.
The deprecated constructor and
listener setters behave as they used to (they prevent the automatic
destruction of the entity), so existing code that upgrades to this version
will not see any difference. However, it is recommended that applications
transition to the new APIs.
.. CORE-10471
Removed some enumerators from DDS_SampleRejectedStatusKind
----------------------------------------------------------
In this release, you can identify why a subscribing application is not seeing
samples using new statistics for lost, rejected, and dropped samples.
See :link_connext_whats_new_610:`What's New in 6.1.0 <>`
As a result of these changes, the following enumerators from
SampleRejectedStatusKind have been removed:
- DDS_REJECTED_BY_UNKNOWN_INSTANCE
- DDS_REJECTED_BY_REMOTE_WRITERS_PER_SAMPLE_LIMIT
- DDS_REJECTED_BY_VIRTUAL_WRITERS_LIMIT
- DDS_REJECTED_BY_REMOTE_WRITERS_PER_INSTANCE_LIMIT
- DDS_REJECTED_BY_REMOTE_WRITERS_LIMIT
If you are using any of these enumerators in your application, they will need
to be removed and you will need to recompile your application.
.. CORE-10175
DataWriter::get_matched_subscriptions and DataReader::get_matched_publications return not alive entities
--------------------------------------------------------------------------------------------------------
Previously, the ``DDS::DataWriter::get_matched_subscriptions`` and
``DDS::DataReader::get_matched_publications`` APIs only returned instance
handles for remote entities that were alive. This was not compliant with
the `OMG Data Distribution Service (DDS) standard API, version 1.4 `_.
Now, these APIs return the instance handles
for any matching remote entities, including those that are not alive.
If you want to use the old behavior, where these APIs only returned instance
handles for remote entities that were alive, use the APIs along with the
new APIs ``DDS::DataWriter::is_matched_subscription_active()``
(to know which matched |DRs| are not active) and
``DDS::DataReader::is_matched_publication_alive()`` (to know which matched |DWs|
are not alive).
.. CORE-9366
Changed get_matched_publication_data and get_matched_subscription_data return value
-----------------------------------------------------------------------------------
``DDS_DataWriter_get_matched_subscription_data`` and
``DDS_DataReader_get_matched_publication_data`` have changed their return value from
DDS_RETCODE_PRECONDITION_NOT_MET to DDS_RETCODE_BAD_PARAMETER when the instance handle
does not correspond to any matched endpoint. This change also affects APIs that use
exceptions instead of return codes (Modern C++, Java, and .NET). The new return value
is now consistent with the API documentation.
.. CORE-10103
.. CORE-9448 is documented in the 6.0.0 regressions section
Library Size
============
The following table shows the different sizes of the main libraries in
|CONNEXT| 6.1.0 versus 6.0.1, for a Linux architecture. The size of the libraries
has increased due to the addition of new code; however, the changes are not
significantly higher.
.. note::
The libraries tested are the *release* versions. The value for each of the
libraries has been obtained as the ``text`` size displayed when using the
``size`` command on Linux.
.. Javi, I think including the tables this way works great.
.. csv-table::
:file: performanceTables/librarySize.csv
:header-rows: 1
Memory Consumption
==================
In general, 6.1.0 applications consume equivalent heap memory to 6.0.1.
.. note::
These numbers should be taken as a rough estimation due to the nature of how
|CONNEXT| reserves memory.
.. csv-table::
:file: performanceTables/heapUsage_x64Linux3gcc4.8.2.csv
:header-rows: 1
Network Performance
===================
In general, 6.1.0 applications have the same performance as in 6.0.1 for user
data exchange. However, some significant performance and scalability improvements
have been done in areas such as discovery and security. For detailed information
on these improvements, see :numref:`section-core-disc-perf`.
The following numbers are taken using *RTI Perftest 3.1* for a Reliable scenario
with unkeyed data.
- **Latency**
.. csv-table::
:file: performanceTables/lat_udpv4_unkeyed_rel_diff_6.0.1.csv
:header-rows: 1
- **Throughput**
.. csv-table::
:file: performanceTables/thr_udpv4_unkeyed_rel_diff_6.0.1.csv
:header-rows: 1
.. Javi, the last column in above table is empty. See the output.
.. _section-core-disc-perf:
Discovery Performance
=====================
Participant Discovery and Endpoint Discovery times have improved
in 6.1.0 compared to 6.0.1.
The following table displays an example of this improvement.
.. note::
This table shows the time to complete Endpoint Discovery based on the
number of Endpoints. For each experiment (row), half the endpoints are
|DRs| and half are |DWs|. Each Endpoint is assigned to a different
Participant, and each Participant belongs to a separate process. All processes
(and therefore all Participants and Endpoints) are deployed in a round-robin
fashion across eight Linux nodes in an isolated lab. All nodes are connected
through 1Gbps NICs to the same network.
.. csv-table::
:file: performanceTables/discoveryNoSecurity.csv
:header-rows: 1
These improvements are not only extensive but even more pronounced when using
*RTI Security Plugins*. See :numref:`section-security-disc-perf`.
.. _section-Micro-610:
RTI Connext Micro Compatibility
===============================
Connext Micro does not interoperate with |DWs| that send compressed data.
For more information about compression, see the
:link_datarep_usersman_610:`DATA_REPRESENTATION QosPolicy section, in the RTI Connext Core Libraries User's Manual <>`.
.. CORE-10341
Miscellaneous
=============
.. _section-Product-other-autodispose_unregistered_instances:
autodispose_unregistered_instances setting no longer applies when deleting |DW|
-------------------------------------------------------------------------------
In previous releases, the deletion of a reliable |DW| where
``autodispose_unregistered_instances`` is set to TRUE may not have caused the
|DW|'s registered instances to transition to DDS_NOT_ALIVE_DISPOSED_INSTANCE_STATE
on the reliable |DR| side. Instead, some instances may have transitioned to the
DDS_NOT_ALIVE_NO_WRITERS state. To address this issue, |DW| deletion is now
treated differently than an explicit call to ``DataWriter::unregister_instance``.
Therefore, the ``autodispose_unregistered_instances`` setting no longer applies
during |DW| deletion and only applies when a |DW| calls ``unregister_instance``
explicitly. Deletion of a |DW| does not dispose of instances anymore, regardless
of how ``autodispose_unregistered_instances`` is set.
In addition, the default value of ``autodispose_unregistered_instances`` has
changed to FALSE. See :numref:`section-Product-configuration-autodispose_unregistered_instances`
for additional details.
.. CORE-7485
New Durable Writer History (database) schema
--------------------------------------------
In 6.1.0, the schema of the storage files and tables created by a |DW|
using durable writer history to store DDS samples and instances has changed.
Therefore, you cannot use the files and/or tables generated with previous
releases.
If you have this requirement, contact RTI Support at support@rti.com.