10.5. Known Issues¶

10.5.1. Logging mechanism is not included by default¶

Connext Cert supports logging in its Debug libraries, but the Platform Support Library (PSL) does not include a default logging mechanism. To see logging, you must set a log handler or log display function in your application.

For more information, see Debugging.

[RTI Issue ID MICRO-8534]

10.5.2. Resources are not freed when calling unregister_instance on a reliable Zero Copy DataWriter¶

When using a reliable Zero Copy DataWriter, calling FooDataWriter_unregister_instance() does not return the instance’s resources to the appropriate pool for reuse.

As a workaround for this issue, you should size the DataWriterQos.resource_limits.max_instances parameter to accommodate the total number of instances that will be used during the lifetime of the DataWriter. This issue is not present when using a DataWriterQos.reliability.kind of DDS_BEST_EFFORT_RELIABILITY_QOS.

[RTI Issue ID MICRO-7253]

10.5.3. Multiple endpoints not matched properly when using Zero Copy¶

When attempting to match DataWriters and DataReaders that are created in already-enabled DomainParticipants, the matching may fail.

This issue can be worked around by creating all endpoints in a DomainParticipant before enabling the DomainParticipant.

[RTI Issue ID MICRO-5790]

10.5.4. Cannot set consistency mode for SharedQWriter to anything but ROBUST¶

Attempting to call NETIO_ZCOPY_SharedQReader_open or NETIO_ZCOPY_SharedQReader_open_by_name on a SharedQReader initialized for consistency mode results in an error if the SharedQ was initialized with a consistency mode other than ROBUST. There is currently no known workaround for this issue.

[RTI Issue ID MICRO-5784]

10.5.5. VOLATILE Zero Copy DataReaders behave as TRANSIENT_LOCAL¶

When a DataReader matches a DataWriter via Zero Copy communication, it has visibility into all samples that are present at that time, independent of its setting for the DURABILITY QoS. This may be unexpected and is not consistent with VOLATILE DataReaders that match to that same DataWriter via other transports.

[RTI Issue ID MICRO-5550]

10.5.6. Samples cannot be reclaimed if Zero Copy application does not return loan¶

If a DomainParticipant subscribing to Zero Copy data dies after reading or taking Zero Copy samples but before returning their loan, or never returns the loan for some other reason, then those samples can never be reclaimed for subsequent publishing and can be considered lost resources.

There is currently no known workaround that entirely removes the risk of samples becoming unavailable for reclaiming. The impact of such a scenario can be decreased by following these recommendations:

On the receiving side, process samples one at a time, by setting the max_samples parameter to 1 when invoking the read() or take() family of functions. This will limit the impact of a dying process to a resource loss of 1 sample at most.
Increase the max_samples resource limit on the DataWriter, to exceed the number of expected matching DataReaders. If the previous recommendation is followed as well, then the sample resources might decrease due to subscribing process failures, but never be exhausted.

[RTI Issue ID MICRO-5834]

10.5.7. Maximum number of components limited to 9¶

The maximum number of components that can be registered by an application is limited to 9, or 10 if the Zero Copy v2 Transport is not enabled.

[RTI Issue ID MICRO-3571]

10.5.8. Static endpoint discovery requires unique object IDs across all remote endpoints¶

When using static endpoint discovery (DPSE), Connext Cert requires that the object_id for statically asserted remote endpoints must be unique across all remote endpoints, as opposed to just among remote endpoints within the same DomainParticipant.

[RTI Issue ID MICRO-211]