queries on timeout and cache cleaning mechanism [14794]

[manojkumarv1]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

As we understood from the fastdds mechanism ,when publisher publishes data and subscriber reads the data based on condition(topic name). But for example if no subscriber is there but publisher publishes data , we have following doubts ...

1. Is there any timeout mechanism we can set ( like till how much time publisher publishes data )

2. cache cleaning mechanism ( is it already there in this API or where the publisher related memory is going to save and how it is getting cleaned after work is done )

Current behavior

unable to find these queries

Steps to reproduce

Build any example where communication is going between publisher and subscriber

Fast DDS version/commit

latest release

Platform/Architecture

Ubuntu Focal 20.04 arm64

Transport layer

Default configuration, UDPv4 & SHM

Additional context

No response

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[JLBuenoLopez]

Hi @manojkumarv1,

I have moved your issue to the proper forum according to our CONTRIBUTING guidelines.

Reading your post, we are not sure what you are trying to do. I will try nevertheless to give you some hints about how DDS works in the hopes that it helps you understand it better. You can always refer to the DDS specification as well to understand better the expected behavior.

From a DDS point of view, publishing and receiving data are independent. The DataWriter publishes data which is added into its own history. If a DataReader is matched with this DataWriter, then it is notified that there is data in the DataWriter's history and depending on the DataWriter operating mode QoS Policy the data will be sent to the DataReader or not. The samples within the DataWriter's history will be kept unless they are overwritten depending on how the History QoS Policy has been set. The samples can also be removed from the DataWriter's history if the Lifespan QoS Policy has been set. I strongly suggest you review the QoS policies available in Fast DDS so you can configure your application correctly. You can also contact our support team if you are interested in having some specific help with your application.

Concerning the cache cleaning, Fast DDS takes charge of removing all the resources once the corresponding DDS entity is deleted calling the specific API (delete_datawriter or delete_participant among others). The memory resources can also be handled setting different QoS: History QoS Policy, Resource Limits QoS Policy, Participant Resource Limits QoS Policy, Writer Resource Limits QoS Policy and Reader Resource Limits QoS Policy.

I hope this information is helpful. Please, try to be more specific if your question has not been answered so we can really understand what you need.