Gaps in the publishing sequence number when viewing RTI Recording Service's recorded database
When viewing recorded data in a database created by RTI Recording Service, if you see gaps in the column of publishing sequence number, it might not indicate that there were samples lost during recording.
This can happen when a DataWriter explicitly calls unregister_instance() with the QoS policy, autodispose_unregistered_instances set to true:
By default, autodispose_unregistered_instances is TRUE, and this QoS policy controls whether the middleware automatically disposes the instance when the DataWriter calls unregister_instance().
When unregister_instance() is called with autodispose_unregistered_instances as true, the DataWriter will send two DATA samples. The first DATA sample contains the update information disposing the instance, and the second contains update information unregistering the instance. The second DATA sample will not enter any DataReader's queue since the information is only useful to the middleware. (Unregistering tells the middleware that the DataWriter does not intend to modify that data-instance any more and therefore no longer has anything to say about the instance, allowing the middleware to recover any resources it allocated for the instance.)
RTI Recording Service is implemented using a DataReader that periodically flushes received traffic into an SQLite database. This DataReader behaves like any other DataReader and does not process the second DATA message that contains the unregister notification. This means the second DATA sample will not enter the reader queue and will not be recorded, causing a gap in the sequence number.
Alternately, this can happen if DataWriter disposes the same instance more than once:
In this case, the DataWriter will send out multiple DATA samples containing update information disposing the instance. It will send out one update for each time the application calls dispose(). The subsequent samples after the first one will be ignored by the middleware, since the state of the instance has changed to NOT_ALIVE_DISPOSED after the first DATA sample is received. This means only the fist DATA sample will be recorded, causing a gap in the sequence number.