2.1.2.1. RTI Connext Core Libraries

The following issues affect backward compatibility in the Core Libraries starting in release 7.2.0. Issues in the Core Libraries may affect components that use these libraries, including Infrastructure Services and Tools.

2.1.2.1.1. Transport Compatibility

2.1.2.1.1.1. Communication with QNX applications in previous releases no longer possible when using shared-memory transport

In previous releases, if a QNX application using the shared-memory transport was ungracefully shut down, crashed, or otherwise had an abnormal termination while holding a POSIX semaphore used by the transport (for example, while sending data through the shared-memory transport), Connext applications launched after that point on the same domain may have waited forever for that semaphore to be released. Running QNX applications using the Connext shared-memory transport may have also led to thread priority inversion issues.

These problems have been fixed in 7.2.0. However, the fix makes communication with applications from a previous Connext version impossible when using the shared-memory transport. If you try to use shared memory with old applications, you will see the following error message(s):

incompatible shared memory protocol detected.
Current version 5.0 not compatible with x.y.

OR

incompatible shared memory protocol detected.
Current version x.y not compatible with 5.0.

There is no way to be backwards-compatible. You will have to use other transports such as UDPv4.

2.1.2.1.2. API Compatibility

2.1.2.1.2.1. RTI Monitoring Library 2.0 builtin QoS profiles renamed

In 7.2.0, the RTI Observability Library was renamed “RTI Monitoring Library 2.0.” Because of this change, the builtin QoS profiles associated with Monitoring Library 2.0 were renamed, too:

• BuiltinQosLib::Generic.Observability was renamed BuiltinQosLib::Generic.Monitoring2.

• BuiltinQosSnippetLib::Feature.Observability.Enable was renamed BuiltinQosSnippetLib::Feature.Monitoring2.Enable.

If your application uses RTI Observability Framework and references any of the profiles above, update the names accordingly.

2.1.2.1.2.2. Year 2038 support

The type that is used to represent seconds in DDS_Time_t (C and C++ API), Time_t (Java API), and Time (Modern C++, C#, and Python API) has changed from a 32-bit integer to a 64-bit integer.

See Configuration Changes and RTI Tools for additional impacts related to year 2038 support.

2.1.2.1.2.3. Constant rti::core::policy::ReceiverPool::LENGTH_AUTO has been replaced

In 7.2.0, the constant rti::core::policy::ReceiverPool::LENGTH_AUTO has been removed and replaced with rti::core::length_auto. If your application code utilized the constant rti::core::policy::ReceiverPool::LENGTH_AUTO, the compilation will fail. To resolve this issue, replace all instances of the removed constant (rti::core::policy::ReceiverPool::LENGTH_AUTO) with the new constant (rti::core::length_auto).

2.1.2.1.2.4. instance_state_recovery_kind changed to instance_state_consistency_kind

RTI has changed the name of the instance_state_recovery_kind field in the RELIABILITY QoS policy to instance_state_consistency_kind, to more accurately reflect its benefit. The QoS field’s values have also changed. For example, in the C API, DDS_RECOVER_INSTANCE_STATE_RECOVERY became DDS_RECOVER_INSTANCE_STATE_CONSISTENCY, and DDS_NO_INSTANCE_STATE_RECOVERY became DDS_NO_RECOVER_INSTANCE_STATE_CONSISTENCY.

2.1.2.1.3. Memory Consumption

2.1.2.1.3.1. Increased availability of instance key values may result in higher memory usage

You can now always call get_key_value to determine which instance has transitioned when a sample with valid_data=FALSE is received, as long as the instance has been seen by the DataReader before.

Before this change, if the instance had previously been detached, then a call to get_key_value would have failed to retrieve the key value. In the context of instance state consistency, this meant that when a DataWriter of an instance regained liveliness after a network disconnection, and the instance transitioned back to ALIVE with invalid_data = TRUE, it was not possible to call get_key_value to identify the instance that was transitioning back to ALIVE. Now, the key value can be retrieved in this situation as long as keep_minimum_state_for_instances = TRUE in the DataReader’s DATA_READER_RESOURCE_LIMITS QoS policy.

This change results in generally higher memory usage, especially for systems with a lot of instances that may be detached.

2.1.2.1.4. Configuration Changes

2.1.2.1.4.1. Reduction in maximum number of Publishers and Subscribers per DomainParticipant

Starting with Connext 7.2.0, the maximum object ID for Publishers and Subscribers has been reduced from 0xFFFFFF to 0xFFFF. This reduction occurs because secure instance state entities (the builtin DataWriter and DataReader used by instance state consistency when security is enabled) must set the top byte of the object key to 0xFF. This change means that a DomainParticipant can now only contain 65535 Publishers/Subscribers (that is, you can have 65535 Publishers and 65535 Subscribers). Previously, this number was 16777215.