7.3. Known Issues with Usability

7.3.1. Cannot open USER_QOS_PROFILES.xml in rti_workspace/examples from Visual Studio

When trying to open the USER_QOS_PROFILES.xml file from the resource folder of one of the provided examples, you may see the following error:

Could not find file : C:\Users\<user>\Documents\rti_workspace\5.3.0\examples\connext_dds\c\<example>\win32\USER_QOS_PROFILES.xml

The problem is that the Visual Studio project is looking for the file in a wrong location (win32 folder).

You can open the file manually from here:

C:\Users\<user>\Documents\rti_workspace\5.3.0\examples\connext_dds\c\<example>\USER_QOS_PROFILES.xml

This issue does not affect the functionality of the example.

[RTI Issue ID CODEGENII-743]

7.3.2. DataWriter’s Listener callback on_application_acknowledgment() not triggered by late-joining DataReaders

The DataWriter’s listener callback on_application_acknowledgment() may not be triggered by late-joining DataReaders for a sample after the sample has been application-level acknowledged by all live DataReaders (no late-joiners).

If your application requires acknowledgment of message receipt by late-joiners, use the Request/Reply communication pattern with an Acknowledgment type (see the chapter “Introduction to the Request-Reply Communication Pattern,” in the Core Libraries User’s Manual).

[RTI Issue ID CORE-5181]

7.3.3. HighThroughput and AutoTuning built-in QoS Profiles may cause communication failure when writing small samples

If you inherit from either the BuiltinQosLibExp::Generic.StrictReliable.HighThroughput or the BuiltinQosLibExp::Generic.AutoTuning built-in QoS profiles, your DataWriters and DataReaders will fail to communicate if you are writing small samples.

In Connext 5.1.0, if you wrote samples that were smaller than 384 bytes, you would run into this problem. In version 5.2.0 onward, you might experience this problem when writing samples that are smaller than 120 bytes.

This communication failure is due to an interaction between the batching QoS settings in the Generic.HighThroughput profile and the DataReader’s max_samples resource limit, set in the BuiltinQosLibExp::Generic.StrictReliable profile. The size of the batches that the DataWriter writes are limited to 30,720 bytes (see max_data_bytes). This means that if you are writing samples that are smaller than 30,720/max_samples bytes, each batch will have more than max_samples samples in it. The DataReader cannot handle a batch with more than max_samples samples and the batch will be dropped.

There are a number of ways to fix this problem, the most straightforward of which is to overwrite the DataReader’s max_samples resource limit. In your own QoS profile, use a higher value that accommodates the number of samples that will be sent in each batch. (Simply divide 30,720 by the size of your samples).

[RTI Issue ID CORE-6411]

7.3.4. Memory leak if Foo:initialize() called twice

Calling Foo:initialize() more than once will cause a memory leak.

[RTI Issue ID CORE-7678]

7.3.5. Wrong error code after timeout on write() from Asynchronous Publisher

When using an asynchronous publisher, if write() times out, it will mistakenly return DDS_RETCODE_ERROR instead of the correct code, DDS_RETCODE_TIMEOUT.

[RTI Issue ID CORE-2016, Bug # 11362]

7.3.6. Type Consistency enforcement disabled for structs with more than 10000 members

TypeObjects cannot be created from structs with more than 10000 members. Applications that publish or subscribe to such types may see errors like the following:

RTICdrStream_serializeNonPrimitiveSequence:sequence length (10005) exceeds maximum (10000)
RTICdrTypeObjectTypeLibraryElement_getTypeId:serialization error: Type
RTICdrTypeObject_fillType:!get TypeId
RTICdrTypeObject_assertTypeFromTypeCode:!create Structure Type
RTICdrTypeObject_createFromTypeCode:!create TypeObject

When the TypeObject can’t be serialized, the type compatibility check between a reader and a writer falls back to exact type-name matching.

See the section “Verifying Type Consistency: Type Assignability” in the RTI Connext Core Libraries Extensible Types Guide for more information.

[RTI Issue ID CORE-8158]

7.3.7. Escaping special characters in regular/filter expressions not supported in some cases

Escaping special characters is not supported in expressions when using the following features:

Partitions
MultiChannel

Every occurrence of a backslash (\) will be considered its own character and not a way to escape the character that follows. For example: A\? does not match A? because the first expression is considered an expression with three characters.

[RTI Issue ID CORE-11858]