9.3. Regressions in 7.3.0

The following regressions were introduced in Connext 7.3.0.

9.3.1. Core Libraries

9.3.1.1. 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]

9.3.1.2. 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 could crash the JVM.

Fixed in: 7.4.0

[RTI Issue ID CORE-14912]

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

Not fixed yet

[RTI Issue ID CORE-15528]

9.3.2. Routing Service

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

Not fixed yet

[RTI Issue ID ROUTING-1288]