.. 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 ===================== 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.