ZettaScale Knowledge Base ZettaScale Knowledge Base

  • Home
  • DDS Products
    • DDS Overview and Concepts
    • OpenSplice DDS
      • OpenSplice DDS
        • OpenSplice FAQ
        • Why OpenSplice DDS?
        • Installation
          • OpenSplice Licensing FAQ
        • Best Practice and Possible Errors
        • API and IDL
        • Configuration
        • Networking
          • DDSI
          • RT Networking
        • Durability Service
        • DDS Security
        • Logging
        • Databases and DBMS
        • Release Notes
      • OpenSplice Tools
        • Overview
        • OpenSplice Launcher
        • OpenSplice Tuner
        • OpenSplice Tester
        • Record and Replay Manager
        • MMStat
    • Cyclone DDS
  • Zenoh
  • Contact Support
Home / DDS, OpenSplice DDS, Best Practice and Possible Errors / Handling ‘invalid data’

Handling ‘invalid data’

A feature was introduced in the OMG DDS rev1.2  specification revision which is about the assurance to receive state-changes (e.g. when data gets disposed and/or unregistered) even in absence of actual data updates. It is related to the read/take semantics where a ‘take’ basically removes the data from a reader-cache.

In the previous spec-revision,  in this situation one couldn’t be made aware/triggered about unregister/dispose actions of a writer since basically there was no sample left of which the sampleInfo would reveal the new instance_state.

To remedy this, it was decided that upon such instance_state changes, if required, a dummy-sample would be created that has its valid_data flag set to FALSE (see 7.1.2.5.1.1 of the OMG-DDS rev1.2 specification). To accommodate users that are not bothered by losing the ability to see instance-state changes for data that has been ‘taken’ from their readers, we have introduced a new readerQoS policy called ‘reader_data_lifecycle.enable_invalid_samples’ that, when set to FALSE (default is TRUE), prevents these ‘dummy-samples’ from being generated.

What people sometimes observe is the ‘unanticipated’ arrival (and related reader-triggering) of these ‘invalid’ samples, especially when legacy code is migrated pre OpenSplice 4.3 versions that where compliant with the DDS rev1.0 or rev1.1 specification. To facilitate easy migration of such applications or to make life easier for people/applications that are not interested in lifecycle-changes of publishing appliations (that perform unregister and/or dispose actions), we’ve introduced a reader QoS policy that prevents these invalid_samples from being generated (and thus observed by applications):

Usability: Migration support from DDS rev1.1 to rev 1.2

a. Feature: Ignore ‘invalid-samples’

b. Summary: a DataReaderQoS policy called “reader_data_lifecycle.enable_invalid_samples” to indicate if invalid-samples are to be generated

c. Defaults: DDS_ReaderDataLifecycleQosPolicy.enable_invalid_samples = TRUE (so to enforce DDS_compliant behavior)

Related

samplesinvalidspecificationOpenSpliceReaderDataLifecycleQoSPolicy DDSOpenSplice DDSBest Practice and Possible Errors
twitter logo linkedin logo
News and Events
Copyright © 2022 ZettaScale Technology Ltd. All Rights Reserved