6.6.2. Fixes Related to Discovery
6.6.2.1. [Critical] Unexpected memory growth when DataReader could not be matched with DataWriter due to unexpected error condition
Failing to match a DataReader with a DataWriter because of unexpected error conditions may have led to unexpected memory growth, because Connext may not have cleaned up the resources associated with the remote match completely. This problem has been resolved.
[RTI Issue ID CORE-8257]
6.6.2.2. [Critical] Possible crash upon discovery of applications with unreachable locators
If an application used DDS_STATUS_MASK_ALL for a DomainParticipant or Publisher Listener and an unreachable locator was discovered, the application enabling the Listener may have crashed. An unreachable locator occurs most commonly when a Subscribing application uses a transport that the Publishing application does not use. For example, the Publishing application could use UDPv4 and the Subscribing application could use both UDPv4 and UDPv6.
More rarely, a crash may have occurred when a pre-5.2.0 Subscribing application used the shared memory transport and a 5.2.0+ Publishing application was not using the UDPv6 transport. A log message was generated if both participants were running on the same machine and this condition occurred. This condition was caused by a change to the way that transports are identified starting in version 5.2.0.
[RTI Issue ID CORE-11818]
6.6.2.3. [Critical] Communication problems with applications using shared memory on INTEGRITY systems
If an application on an INTEGRITY platform used the shared-memory transport, the Connext libraries sometimes incorrectly assessed that a shared-memory segment was stale and could be reclaimed, when in fact it was not stale. This situation caused problems with communication between DomainParticipants, since information could be sent to a shared-memory segment that did not get dequeued by the intended recipient.
You may have seen error messages like these and the application may have hung while deleting the DomainParticipant:
<Target Output> ERROR RTIOsapiSharedMemoryBinarySemaphore_take:OS WaitForSemaphore() failure, error 0XD: ObjectClosed
<Target Output> ERROR NDDS_Transport_Shmem_receive_rEA:!take semaphore
<Target Output> ERROR RTIOsapiSharedMemoryBinarySemaphore_take:OS WaitForSemaphore() failure, error 0X9: ObjectIsUseless
This problem has been resolved.
[RTI Issue ID CORE-12097]
6.6.2.4. [Critical] Unbounded memory growth in Spy when discovering multiple endpoints with the same Topics and types
Each time DDS Spy discovered an endpoint, it unnecessarily made a copy of the TypeCode that was associated with the endpoint’s Topic, leading to unbounded memory growth. This issue has been fixed.
[RTI Issue ID CORE-12136]
6.6.2.5. [Major] Types containing Typedefs were sent without the typedefs in discovery when using DynamicData
When an application was using a DynamicDataReader or DynamicDataWriter and using a type that contained a typedef, the type that was sent during endpoint discovery for that endpoint did not contain the typedef. While this did not cause any mismatches or communication failure, it did cause a number of issues that may have been noticeable depending on what other products you may have also been using.
See “Unbounded memory growth in Spy when discovering multiple endpoints with the same Topics and types,” below, for details about the specific issues that you may have encountered. The RTI Admin Console Release Notes and RTI Routing Service Release Notes also have related information. (See ADMINCONSOLE-997 and ROUTING-971, respectively.)
This issue has been resolved, meaning that the exact type definition that is registered with the participant, containing typedefs, is sent during discovery. This is a change in behavior from 6.0.0-based applications, which sent the type definitions without the typedef information.
[RTI Issue ID CORE-12107]
6.6.2.6. [Major] Unnecessary discovery traffic related to IP mobility events on interfaces irrelevant to the transport
When there is a change on a network interface (an IP mobility event), a Connext application will update and resend its discovery information to include these changes. The transport can consider a change on an interface irrelevant (for example, changes on interfaces in the deny_interfaces_list of the transport). In this case, the new discovery messages are exactly the same as announced before, generating unnecessary discovery traffic that could affect the performance of the application.
This problem has been fixed. Now Connext only updates and resends its discovery information if there was a change on an interface relevant to the transport.
[RTI Issue ID CORE-12664]