Jump to content
OpenSplice DDS Forum

aaron.panella

Members
  • Content Count

    4
  • Joined

  • Last visited

About aaron.panella

  • Rank
    Member

Profile Information

  • Company
    elmTEK
  1. Hi Erik, I've finally got back around to this issue - I replaced my keyed topics with keyless topics. After some initial issues receiving (incorrectly configured viewstate) I managed to get my application working again. It seems as though it is no longer leaking. I will leave it running in the background and monitor it, but I believe you've provided me with the fix to this issue. Thank you for taking the time to provide me with more insight into OpenSplice Best Regards, Aaron
  2. Thanks Erik, There is no real reason for me to use keys here, I'm really only using one topic instance per topic type, one publisher, one subscriber. I will change to keyless topics and KEEP_ALL Best Regards, Aaron
  3. Hi Erik, Thanks for the quick reply. Actually yes, I am using a keyed topic, and yes, I am generating the key from an unsigned short "id", which I am incrementing each time I send a new sample. My writer exists for the lifetime of my application, so it sounds like you are right. I will use the unregister_instance operation first thing tomorrow and report back. Thanks once again Best Regards, Aaron
  4. Hi all, I am a bit new to DDS/OpenSplice - I've written a transmitter and receiver that streams video using pub/sub (I'm not using OpenSplice Streams though, just DCPS). It all seems to work perfectly, however, when it is running over a long period of time, for the reader application, the memory usage will increase in every thread, until the kernel OOM kills my application. This smells like a memory leak but I checked it with valgrind and it seems fine. Additionally, stopping the data stream frees up the memory, so if it was leaking I wouldn't expect that to happen. I've set up my QoS as best I can, in order to achieve what I like. I want max throughput, and don't care if I drop a sample or two along the way. So I've set to volatile so that dropped samples aren't stored anywhere, but I suspect somewhere, some stuff is being stored in memory. So anyway, I suspect that this is just a QoS/configuration issue - are there any QoS policies I may have missed that could cause this to occur? Here are the ones I've configured in my initializer list, I guess all other policies would be using the defaults: reader_topic_qos_{dp_.default_topic_qos() << dds::core::policy::Durability::Volatile() << dds::core::policy::Lifespan(dds::core::Duration(1,0)) << dds::core::policy::Liveliness(dds::core::policy::LivelinessKind::AUTOMATIC ,dds::core::Duration(1,0)) << dds::core::policy::ResourceLimits(10) << dds::core::policy::Reliability::BestEffort()}, Thanks for your time
×
×
  • Create New...