10.3. Regressions in 7.3.0

The following regressions were introduced in Connext 7.3.0.

10.3.1. Core Libraries

10.3.1.1. Duplicate network traffic captures when creating WaitSets, AsyncWaitSets, or GuardConditions

Creating WaitSets, AsyncWaitSets, or GuardConditions could cause the same DomainParticipantFactory instance to be added multiple times to an internal global list of all the DomainParticipantFactories in an application. As a result, Network Capture (which uses the global list) may capture traffic from the same DomainParticipants multiple times.

After fixing this problem, the DomainParticipantFactory instance is no longer added multiple times in this case and, consequently, Network Capture no longer captures DomainParticipants’ traffic multiple times.

Fixed in: 7.6.0

[RTI Issue ID CORE-15913]

10.3.1.2. Error when setting QoS on Publisher or Subscriber without endpoints

When changing the Partition QoS Policy of Publishers or Subscribers without endpoints (DataWriters or DataReaders), the operation can unexpectedly fail and log this error:

FAILURE | Notify of group or partition change.

The likelihood of running into this issue increases with the number of Publishers or Subscribers created by your application.

Fixed in: 7.5.0

[RTI Issue ID CORE-15322]

10.3.1.3. Crash on DDS_DomainParticipantFactory_finalize_instance when using XML-Based Application Creation

When using XML-Based Application Creation with multiple registered types, DDS_DomainParticipantFactory_finalize_instance can crash the JVM.

Fixed in: 7.4.0

[RTI Issue ID CORE-14912]

10.3.1.4. Unexpected error messages when disposing of an instance while using batching and setting serialize_key_with_dispose to TRUE

Consider the following DataWriter QoS:

<datawriter_qos>
    <batch>
        <enable>true</enable>
    </batch>
    <protocol>
        <serialize_key_with_dispose>true</serialize_key_with_dispose>
    </protocol>
</datawriter_qos>

The data type is keyed, and the serialized key is not aligned to a 4-byte boundary.

Imagine that DataWriter1 registers an instance, and then DataWriter2 uses the resulting InstanceHandle to write and dispose that instance. DataWriter2 successfully sends one batch with a data sample of a given instance and then attempts to send another batch whose first sample is a dispose message for that same instance.

When using release libraries, DataWriter2 will successfully send the second batch, but the DataReader that is reading the batch from DataWriter2 will experience this error:

ERROR MIGInterpreter_parse:submessage not aligned to 4

When using debug libraries, DataWriter2 will fail to send the batch and will generate this error:

mig.2.0/srcC/generator/Generator.c:1216:RTI0x200003a:!precondition: "!(sample != ((void *)0) && (((sample)->serializedData[encapsulationIndex].serializedData.pointer == ((void *)0) || ((sample)->serializedData[encapsulationIndex].serializedData.length & 0x3) == 0)) && (((sample)->protocolParameters.pointer == ((void *)0) || ((sample)->protocolParameters.length & 0x3) == 0)))

After fixing this problem, DataWriter2 will successfully send the batch, and the DataReader will successfully receive the batch when using either release or debug libraries.

Fixed in: 7.6.0

[RTI Issue ID CORE-15528]

10.3.1.5. RTI DDS Spy shows DDS_DataReader_get_matched_publication_participant_data error before leaking memory

When discovering the deletion of a DataWriter or DataReader immediately after discovering the deletion of the DomainParticipant associated with the DataWriter or DataReader, DDS Spy incorrectly generates these errors before leaking memory:

DDS_DataReader_get_matched_publication_participant_data:ERROR: Failed to get discovered_participant_data
get_matched_publication_participant_data error 4
ERROR DDS_SampleInfoSeq_set_maximum:failed to assert buffer must not be loaned

Fixed in: 7.6.0

[RTI Issue ID CORE-15629]

10.3.1.6. Misleading warning message when one non-loopback interface doesn’t support multicast

If the network interfaces on a machine include an interface that supports multicast and a non-loopback interface that does not support multicast, and you send a multicast packet from the machine, then a warning message like this one will incorrectly appear:

NDDS_Transport_UDP_send:FAILED TO SEND | Message with 64 bytes over 2 interface(s). Total bytes sent: 64. Total bytes to send: 128.

In this example, the multicast packet is 64 bytes, and Connext is incorrectly trying to send it over two interfaces instead of one (hence, the 128). This problem has been fixed by only trying to send the packet over the interface that supports multicast.

Fixed in: 7.6.0

[RTI Issue ID CORE-15833]

10.3.2. Admin Console

10.3.2.1. Discovery peer changes not consistently applied or maintained

After editing a DomainParticipant to add or remove discovery peers, the changes might not be applied to future participants on the same domain ID.

As a workaround, remove and re-add the new peer:

Click Edit DomainParticipant(s), delete the peer, then click Apply.
Click Edit DomainParticipant(s), re-add the new peer, then click Apply.

Fixed in: 7.6.0

[RTI Issue ID ADMINCONSOLE-1450]

10.3.3. Routing Service

10.3.3.1. Unexpected error messages when Routing Service disposes of an instance while using batching and setting serialize_key_with_dispose to TRUE

Consider the following Routing Service writer QoS:

<datawriter_qos>
    <batch>
        <enable>true</enable>
    </batch>
    <protocol>
        <serialize_key_with_dispose>true</serialize_key_with_dispose>
    </protocol>
</datawriter_qos>

The data type is keyed, and the serialized key is not aligned to a 4-byte boundary.

Imagine that Routing Service successfully sends one batch with a data sample of a given instance and then attempts to send another batch whose first sample is a dispose message for that same instance.

When using release libraries, Routing Service will successfully send the second batch, but the DataReader that is reading the batch from Routing Service will experience this error:

ERROR MIGInterpreter_parse:submessage not aligned to 4

When using debug libraries, Routing Service will fail to send the batch and will generate this error:

mig.2.0/srcC/generator/Generator.c:1216:RTI0x200003a:!precondition: "!(sample != ((void *)0) && (((sample)->serializedData[encapsulationIndex].serializedData.pointer == ((void *)0) || ((sample)->serializedData[encapsulationIndex].serializedData.length & 0x3) == 0)) && (((sample)->protocolParameters.pointer == ((void *)0) || ((sample)->protocolParameters.length & 0x3) == 0)))

After fixing this problem, Routing Service will successfully send the batch, and the DataReader will successfully receive the batch when using either release or debug libraries.

Fixed in: 7.6.0

[RTI Issue ID ROUTING-1288]