Jump to content
OpenSplice DDS Forum

Troubles with transient durability topic QoS

Recommended Posts


I have some trouble with the transient durability that I use on a topic. It does not seems to work. If a wrtier is created and send a sample, a reader that comes later cannot access those data (read operation returns with a status  DDS_RETCODE_NO_DATA. Everything works fine if the reader is created (or try to read, i'm not sure) before the sample is written.

I'm using OpensSplice 6.9 community on windows 7 x64.

my code is a variation of the chat tutorial. Here is the code used to create the topic and its QoS, it is done the same on the reader and writter executable:

	/* Obtain a private copy of the default QoS to tailor it. */
	setting_topic_qos = DDS_TopicQos__alloc();
	checkHandle(setting_topic_qos, "DDS_TopicQos__alloc");
	status = DDS_DomainParticipant_get_default_topic_qos(dp, setting_topic_qos);
	checkStatus(status, "DDS_DomainParticipant_get_default_topic_qos");
	/* Note: changing the copy doesn't change the original itself!*/
	setting_topic_qos->durability.kind = DDS_TRANSIENT_DURABILITY_QOS;

	nameServieTopic = DDS_DomainParticipant_create_topic(dp, "Chat_NameService", nameServicetypeName, setting_topic_qos, NULL, DDS_STATUS_MASK_NONE);
	checkHandle(nameServieTopic, "DDS_DomainParticipant_create_topic");

here is the writer :

dw_qos = DDS_DataWriterQos__alloc();
	checkHandle(dw_qos, "DDS_Publisher_create_datawriter");
	status = DDS_Publisher_get_default_datawriter_qos(chatPublisher, dw_qos);
	checkStatus(status, "DDS_Publisher_get_default_datawriter_qos");
	status = DDS_Publisher_copy_from_topic_qos(chatPublisher, dw_qos, setting_topic_qos);
	checkStatus(status, "DDS_Publisher_copy_from_topic_qos");
	dw_qos->writer_data_lifecycle.autodispose_unregistered_instances = FALSE;
	nameServer = DDS_Publisher_create_datawriter(chatPublisher, nameServieTopic, dw_qos, NULL, DDS_STATUS_MASK_NONE);
	checkHandle(nameServer, "DDS_Publisher_create_datawriter");


here is the reader :

sub_qos = DDS_SubscriberQos__alloc();
	checkHandle(sub_qos, "DDS_Subscriberqos__alloc");
	status = DDS_DomainParticipant_get_default_subscriber_qos(dp, sub_qos);
	checkStatus(status, "DDS_DomainParticipant_get_default_subscriber_qos");
	sub_qos->partition.name._length = 1;
	sub_qos->partition.name._maximum = 1;
	sub_qos->partition.name._buffer = DDS_StringSeq_allocbuf(1);
	checkHandle(sub_qos->partition.name._buffer, "DDS_StringSeq_allocbuf");
	sub_qos->partition.name._buffer[0] = DDS_string_alloc(strlen(partitionname));
	checkHandle(sub_qos->partition.name._buffer[0], "DDS_string_alloc");
	strcpy(sub_qos->partition.name._buffer[0], partitionname);

	chatSubscriber = DDS_DomainParticipant_create_subscriber(dp, sub_qos, NULL, DDS_STATUS_MASK_NONE);
	checkHandle(chatSubscriber, "DDS_DomainParticipant_create_subscriber");

	nsReader = DDS_Subscriber_create_datareader(chatSubscriber, nameServieTopic, DDS_DATAREADER_QOS_USE_TOPIC_QOS, NULL, DDS_STATUS_MASK_NONE);



What really troubles me is that using executable create by compilling the example given with OpenSplice i got the exact same behaviour. If i launch the chatter before the messageboard, then it is unable to retrive the chatter name, while if I launch the messageboard first, then it can retrieve the chatter name without any trouble.

Why is that ? why does transient durability does not work ? Even with the source code provided in the release ?

Share this post

Link to post
Share on other sites

Looks like you're indeed setting up the topicQos correctly to indicate that the data is TRANSIENT (so to instruct a/any durability-service to 'maintain' that non-volatile data).

Also looks like your writer is indeed also writing TRANSIENT data (as you exploited the copy_from_topic_qos() utility)

Yet looks  like you're forgetting to do the same for the reader, in which case the durability-service won't bother providing its data to that reader (unless you explicitly call wait_for_historical_data() but typically you wouldn't need that if the reader was setup as TRANSIENT

Finally, the chatroom is a little tricky w.r.t. its multitopic-emulation which can sometimes imply quick adaptations to overlook some dependencies, but its a long time ago since I last looked at that so would suggest first to assure that your reader(s) are also setup with TRANSIENT QoS.

Share this post

Link to post
Share on other sites

But for my writer I used the DDS_DATAREADER_QOS_USE_TOPIC_QOS. Since the topic is set up to have TRANSIENT durability shouldn't my reader also use TRANSIENT then ?

As for the multitopic thing, it's exactly where my version differs for the most part. I got rid of this multitopic emulation to simplify it to just test the kind of things that I will need in my real application (I'm still in the learning phase for now, gathering the info that will be usefull). Instead of crating a pseudo multi-topic with a listener i just print info from 2 topic.

Share this post

Link to post
Share on other sites

When you create your reader, you have to set its reader-qos to transient too:

If you look at the bundled 'Durability' example you'll see the following code (in the 'entitymanager.c') to create a transient reader:

void createReader()
   DDS_DataReaderQos *dataReaderQos = DDS_DataReaderQos__alloc();
   DDS_TopicQos *topicQos = DDS_TopicQos__alloc();
   checkHandle(dataReaderQos, "DDS_DataReaderQos__alloc");
   checkHandle(topicQos, "DDS_TopicQos__alloc");

   g_status = DDS_Subscriber_get_default_datareader_qos(g_Subscriber, dataReaderQos);
   checkStatus(g_status, "DDS_Subscriber_get_default_datareader_qos");
   g_status = DDS_Topic_get_qos(g_Topic, topicQos);
   checkStatus(g_status, "DDS_Topic_get_qos");
   g_status = DDS_Subscriber_copy_from_topic_qos(g_Subscriber, dataReaderQos, topicQos);
   checkStatus(g_status, "DDS_Publisher_copy_from_topic_qos");

   g_DataReader = DDS_Subscriber_create_datareader(g_Subscriber, g_Topic, dataReaderQos, NULL, DDS_STATUS_MASK_NONE);
   checkHandle(g_DataReader, "DDS_Subscriber_create_datareader");


Maybe good to run/example that durability-example too ?

Share this post

Link to post
Share on other sites

Ok I did some more test and found out 2 things :

  1.  DDS_DATAREADER_QOS_USE_TOPIC_QOS works fine my reader is indeed set in transient since the topic is in transient
  2. my reader finally did manage to find data, but it took him about 15 second before being able to see it. Meaning that it took about 15 sec from the moment the sample was supposedly sent by the writter and the moment it was seen by the reader.

Why there is as much as a delay ? The other message that i send, who are in volatile durability are transmited immediately between my writter and my reader. why those transient messages took so long ?

The delay is even greater if i have more writter and different instances of this topic.


Share this post

Link to post
Share on other sites

Your 'late-joining-reader' will exploit its built-in durability-service which in his turn has to 'align' with other durability-services in the system (such as the one of the writer that maintains his 'TRANSIENT' data).

This alignment-process amongst durability-services has several stages, some of which are configurable and could easily take a few seconds .. 15 seconds seems a lot though ..

PS> if you'd select TRANSIENT_LOCAL rather than TRANSIENT, you shouldn't see any delays but then you're basically depending on the writer still being present when you start your late-joining reader. Noting that with the community-edition we don't include 'federated-deployment' which would allow you to start a federation (inclusive a durability-service) and keep that running independent of coming/going applications .. whereas when using the community-edition, you'd have to 'emulate' that by creating an application that 'just'/only creates a domainParticipant and as long as that application is running, you'll have an active durability-service that will maintain TRANSIENT/PERSISTENT data for any late-joiners in your system.


Share this post

Link to post
Share on other sites

I decided to do a little experiment using the bundled ishapes demo example.

I noticed that when I create a transient-writer of blue-circles and pauze that after it has been running for a while and then start another ishapes application where I create a transient-reader with history 100, I immediately get all 100 historical sample which then looks something like this (writer on top, reader bottom):


So no 6 or even 15 second delay, which makes it even more puzzling why you see such a long delay .. 

Share this post

Link to post
Share on other sites

Ok thanks for the quick responses.

Maybe it's because I'm on a VM.

I tried to make another application that just created a domainparticipant then when idle until closed, and I launched it befor launchin the others. it have helped a little bit, my delais dropped to about 10 seconds.

Share this post

Link to post
Share on other sites

you could try using TRANSIENT_LOCAL durability as that doesn't involve any durability-services (and alignment between them) ..

Share this post

Link to post
Share on other sites

Ok I tried outside of the VM and I have a 7 second latency. So the VM did slow down the alignment process.

There is some other strange behaviour but i attriute them to a quick and dirty coding.

unfortunately I will be stuck with transient as i will have to do an app that will have to interact with a system that was already designed and therefore impose me the QoS policy (I'll have to design a test program for a ECU).

But now that I know the limitations it's not that complicated to find a way around them. I just have to be sure that my reader are launched before the ECU and it's writer.

Anyway, bedankt for the help understanding all that.

Share this post

Link to post
Share on other sites

if necessary, the 7 seconds could be reduced somewhat by different (non-default) configuration options in durability .. but if not needed, I wouldn't touch them :)

Good luck with your project.

PS> you write 'bedankt' .. are you Dutch (too)?

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...