Understanding the TRANSIENT durability QOS

[tmayoff]

I have a setup with a single publisher and 2 subscribers (here), all of which with the TRANSIENT durability.

1. A subscriber is setup and listening
2. A writer is setup and a message sent
3. The first subscriber receives the message
4. The writer goes out of scope and is removed
5. A new subscriber is created
6. Both the first and second subscriber receive the message

I'd assume just the new subscriber would be notified not both, is this how it's supposed to work?

[jrw972]

Short Answer

That's a bug. The sender should not send it to the existing reader and the existing reader should be smart enough to filter it out.

Long Answer

Transient and persistent were implemented a long time ago. Not to speak ill of the dead or past contributors, but the implementation took certain liberties with the spec which is itself vague. For instance, the spec assumes a "persistence service" and implies that it may be on a remote node (section 2.3.3.4):

In other words, it is “as if” somewhere in the system (possibly on a remote node) there was a “built-in durability DataReader” that subscribed to that Topic and a “built-in durability DataWriter” that published that Topic as needed for the new subscribers that join the system.

Instead of adding a separate service, the implementers of transient and persistent implemented the service locally.
Furthermore, the documentation says that the data is stored by the publisher so the data outlives the writer but not the publisher.
It seems like a small win if you get to delete the writer but not the publisher.

In your example, you are using the default transport which is TCP.
If you were using RTPS, it would be completely broken because the RTPS spec does not describe how to implement the transient and persistent qos policies.
See https://opendds.readthedocs.io/en/latest-release/devguide/introduction.html#opendds-rtps-implementation-notes

To circle back, transient and persistent are broken because nobody uses them and nobody uses them because they are broken.

[tmayoff]

That's unfortunate, is there a way to get transient like behaviour without over complicating my client code? Is this something that would be fixed along with the mentioned large changes for OpenDDS 4? Is the fix for something like this something an outside contributor could do?

[jrw972]

I haven't executed your code but my guess is that the data writer and publisher are not being destroyed when pub goes out of scope. The participant retains a reference to the publisher which retains a reference to the datawriter. This is why delete_datawriter, delete_publisher, and delete_contained_entities exist. You can test this by setting -DCPSTransportDebugLevel 7 and looking for the DataWriterImpl destructor. Theoretically, you should be able to change from TRANSIENT to TRANSIENT_LOCAL and it should work the way you expect. By the way, you might want to make your datareaders reliable, even though you get that by default with the TCP transport.

This might get fixed in OpenDDS 4 but probably not. This is the second issue in 5 years that I have seen that is related to transient durability so it's not really something that most users are interested in. Moreover, one of the themes for 4 and beyond is focusing on interoperable transports, i.e., RTPS, where possible. As I mentioned earlier, RTPS does not provide guidance for implementing transient and persistent except to provide an inline qos that would probably be necessary if someone decided to do a custom implementation. The existing TCP transport will be reworked to be RTPS over TCP so support for transient and persistent will probably be removed at that point.

Fixing the bug would be a matter of tracing the activity when the second datareader starts. Roughly, this would be:

1. New subscription and match in Sedp.cpp.
2. This should cause the durable data for the writer to be replayed.
3. Durable data makes its way down to the TCP transport and data link. The bug is probably here because it shouldn't be sending to the existing subscriber.
4. Data is received by existing subscriber.
5. There should be a sequence number check that is applied in the transport or perhaps in the DataReader. In either case, it should drop the message because it already has it.