10.1.4. Troubleshooting

This section aims to give quick solutions to overcome the most common problems arising from the use of the statistics module.

10.1.4.1. Monitoring application is not receiving any statistic data

Sometimes, especially in the case of monitoring large applications with many DataWriters and DataReaders, it may happen that the application monitoring Fast DDS statistics does not receive any data. This is generally caused by the default configuration of the statistics DataWriters, which includes the push_mode set to false (i.e. pull_mode), the History Kind set to KEEP_LAST, and the History Depth set to 1. With this configuration, the following may happen:

  1. Fast DDS adds a new sample to one of the statistics DataWriters.

  2. The DataWriter notifies the DataReader of the availability of said sample.

  3. The DataReader sends a request to the DataWriter to “pull” that sample.

  4. Before the request arrives to the DataWriter, a new statistics sample is added to that same DataWriter, which causes the previous sample to be overwritten.

  5. Once the DataReader request arrives to the DataWriter, since the requested sample has been overwritten, it is not available any more, so the DataWriter send a notification to the DataReader informing of the presence of the newer sample instead.

  6. The loop starts again.

The easiest fix to overcome this situation is to simply increase the History Depth of the DataWriter to create Some buffer to answer to requests:

<?xml version="1.0" encoding="utf-8"?>
<dds xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
    <profiles>
        <participant profile_name="statistics_domainparticipant_conf_xml_general_profile">
            <rtps>
                <propertiesPolicy>
                    <properties>
                        <!-- Activate various Fast DDS Statistics Module DataWriters -->
                        <property>
                            <name>fastdds.statistics</name>
                            <value>HISTORY_LATENCY_TOPIC;DISCOVERY_TOPIC;PHYSICAL_DATA_TOPIC</value>
                        </property>
                    </properties>
                </propertiesPolicy>
            </rtps>
        </participant>

        <!-- Generic profile for all the statistics DataWriter -->
        <data_writer profile_name="GENERIC_STATISTICS_PROFILE">
            <!-- Configure History QoS as KEEP_LAST 10 -->
            <topic>
                <historyQos>
                    <kind>KEEP_LAST</kind>
                    <depth>10</depth>
                </historyQos>
            </topic>
            <!-- Enable pull mode -->
            <propertiesPolicy>
                <properties>
                    <property>
                        <name>fastdds.push_mode</name>
                        <value>false</value>
                    </property>
                </properties>
            </propertiesPolicy>
            <!-- Set durability, reliability, and publication mode -->
            <qos>
                <durability>
                    <kind>TRANSIENT_LOCAL</kind>
                </durability>

                <reliability>
                    <kind>RELIABLE</kind>
                </reliability>

                <publishMode>
                    <kind>ASYNCHRONOUS</kind>
                </publishMode>
            </qos>
        </data_writer>
    </profiles>
</dds>

Note

Increasing the History Depth of the statistics DataWriters has an impact on memory usage, as sufficient space is pre-allocated for each of the DataWriter’s histories to hold that number of samples per topic instance.