I have tried to implement the Durability QoS on both OpenSplice and OpenDDS.While I have been successfully done it for OpenDDS,it's been mixed results with OpenSplice.Hence I am posting the issue here for OpenSplice:
I have set the durability related qos policies(topic and datawriter on publisher side and topic and datareader on subscriber side),but when I run the subscriber after the publisher has already transmitted some samples,the old samples are not retrieved.I have been tinkering with these policies for teh last two weeks...have gone through ospl error and info logs ..I did manage to do it successfully around 2 weeks back...but since then no luck...i am attaching the the source of teh application...i am doing it in linux... steps to build: run the makefile to build it...run the pub and sub in different terminals...
The first line will return after all historical data has been delivered to the reader. If you attach the listener after that, it will not trigger on the historical data. Listeners are event-based and only trigger at the moment that new data is delivered, not after it has been delivered.
In stead of attaching a listener, you could call the take() method right from the main.
By the way, I mentioned that you have some strange choices for your QoS-es. Durability is not intended to be combined with Best Effort.
The INFO report is 'as it says' not an erorr/warning just information about an optional setting that allows memory-pages of services to be locked in memory which in some circumstances can yield better determinism as pages can not be swapped-out by the OS anymore.
Took a quick look at your publisher code (without running it yet..) and noticed that you don't create the topic with the properly configured topic_qos structure (that has durability set to TRANSIENT) but that instead you create it with TOPIC_QOS_DEFAULT which implies VOLATILE durability.
Hi Hans, Thanks for your response. Actually I tried to post this issue in Opensplice Google Group,but since I could not upload the attachment,I decided to go for this forum.
My bad luck that the code I had attached had the topic QoS as Default.I have changed it and the observation is that the subscriber throws a segmentation fault.I tried to debug the subscriber and found the following issue::
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7751b90 (LWP 12392)] 0x08056c55 in HelloWorldListener::on_data_available (this=0x83295e0, reader=0x0) at Subscriber.cpp:46 46 ANY_SAMPLE_STATE, ANY_VIEW_STATE, ANY_INSTANCE_STATE);
Further to the above issue,if I restart the ospl daemon,the sub runs fine once.After that almost all the time the segmentation fault happens.However,sometimes it runs fine,even shows some old samples. I do see the following in osplerror.log: ================================================================================ ======== Report : ERROR Date : Tue May 25 16:24:44 2010 Description : Create kernel entity failed. For Topic: <sample> Node : opendds1 Process : 12891 Thread : main thread b7b666c0 Internals : V4.3/u_topicNew/u_topic.c/106/0/370762659 ================================================================================ ======== Report : ERROR Date : Tue May 25 16:24:44 2010 Description : Invalid TopicDescription Node : opendds1 Process : 12891 Thread : main thread b7b666c0 Internals : V4.3/CCPP/ccpp_Subscriber_impl.cpp/58/0/370944279
I also see the following log in osplinfo when the segmentation fault happens: ================================================================================ ======== Report : INFO Date : Tue May 25 16:33:39 2010 Description : service 'durability': MemoryLocking disabled Node : opendds1 Process : durability (13380) Thread : main thread b7c458d0 Internals : V4.3/lockPages/u_service.c/163/0/319718080 ================================================================================ ======== Report : INFO Date : Tue May 25 16:33:39 2010 Description : Durability identification is: 284218336 Node : opendds1 Process : durability (13380) Thread : main thread b7c458d0 Internals : V4.3/DurabilityService/d_durability.c/419/0/463010799 ================================================================================ ======== Report : WARNING Date : Tue May 25 16:39:28 2010 Description : Forcing user-layer detach while still referenced 1 time. Node : opendds1 Process : 13506 Thread : main thread b7b8f6c0 Internals : V4.3/u_userExit/u_user.c/71/0/799065952 ================================================================================ ======== Report : WARNING Date : Tue May 25 16:39:28 2010 Description : User layer not initialized Node : opendds1 Process : 13506 Thread : b7b8eb90 Internals : V4.3/u_userDetach/u_user.c/185/1/799723675
Can someone explain the meaning of these messages??
very strange, it works fine with 5.1 but with 4.3 I had to uncomment the 'cout' in the lifeliness-changed call-back to make it work ...
can you try that 'fix' too ?
posted on Wednesday, May 26, 2010 - 08:18 am
Thanks Hans for running the example.Indeed I am using version 4.3(will try out on 5.1 soon). As I informed in my earlier post about the segmention fault,I handle it by returning from the on_data_available callback if the DataReader object is sent as Null.Why the reader object comes as null is probably a different question. That way I have got my Transient Durability to work as expected. However,when in case of persistent durability,I can see the xml file in the storage directory(sample.xml in my case) getting updated when the publisher is running.But as soon as the publisher terminates,the size of the sample.xml file gets back to 57 bytes.After running the publisher again,the samples from the past session are not retrieved. I am once again attaching my application.I am forced to comment out the durability service qos settings of the topics on both sub and pub as otherwise the pub would crash due to failure in creating the topic.
You've run into a very common pittfall w.r.t. the default-value of the autodispose_unregistered_instances QoS policy. This policy is by default set to TRUE implying that when your application terminates (and implicitly unregisters its instances), this QoS policy setting will also automatically cause the transient and/or persistent data built-up for those instances being disposed and subsequently being cleaned-up (also from the persistent-store).
So in your writer you should add the following: dw_qos.writer_data_lifecycle.autodispose_unregistered_instances = FALSE;
Now you can safely terminate your writer without impacting the availability of non-volatile data for late-joiners.
posted on Wednesday, May 26, 2010 - 03:40 pm
Thanks Hans once again...that solved the problem.However,I feel the ospl daemon also caches some data..because even after deleting the persistent data source(sample.xml) the subscriber was still getting past data.However,once ospl daemon was restarted,old samples were gone...hence,probably it caches them??
You should view persistent data as a subset of transient data, so when you remove the persistent-store, that will only impact the ability to re-inject that data during a subsequent system restart yet it won't impact the availability of that data while the system is still running.
I am having similar issue, using opensplice dds as well
I have tried with datarwriter autodispose = off. Setting my topic with keep_all_history, or keep_history_depth and then set it as default topic qos and have data_writer copied from topic qos either implicitly through macro or explicitly through helper functions.
On the data_reader side, under any configurations, I am only able to receive the last message.
My environment has 1 pub/1sub. The pub exits after writing, typically, and sub joins after all message have been written. I have also tried to put the pub into an infinite sleep after publishing but same result every time.
After 2 days I am at my wits' end. I can post my code snippet if it helps.
Perhaps you're confusing the (dataReader) HISTORY QoS policy with the topic DURABILITY QoS. Wherease the history drives the 'ability' of the dataReader to store a number of arrived samples for each 'instance' i.e. unique key-value (instead of overwriting old-data with new-data for each instance), its the DURABILITY QoS that when set to TRANSIENT or PERSISTENT will instruct the middleware to retain such non-volatile data for delivery to late-joining applications (dataReaders). When you mention the 'autodispose' setting (of FALSE) this suggests that you're interested in 'durability' rather than 'history' ..
I finally got it working last night. As it turn out I needed both because I believe default history depth is 1 on OpenspliceDDS datareader.
So on publisher side I have TRANSIENT, KEEP_ALL_HISTORY_QOS, max_samples_per_instance set for Topic QOS, and Datawriter Qos having autodispose "off"
On the subscriber, the Topic QOS is matched with publisher's but datareader has a new history depth. (This did the trick)
I was definitely confused with the durability qos from topic, which has a history_depth field like Datareader's history qos. I was seeing the last message being saved but couldn't retrieve priors despite durability qos depth is set to 1000.
If you know any online resource on good design patterns for DDS messaging system let me know. I am trying to figure a scheme where one publisher multicast to multiple subscribers but as soon as the last sub gets the message, the middleware no longer needs to keep it around.