Fast-DDS icon indicating copy to clipboard operation
Fast-DDS copied to clipboard

Erroneous "Writer xx.xx.xx.xx.xx.xx.xx.xx.xx.xx.xx.xx|x.x.x.x not found." [13698]

Open ma30002000 opened this issue 4 years ago • 1 comments

When creating multiple fastdds::dds::Publisher s and their corresponding fastdds::dds::DataWriter on the same fastdds::dds::DomainParticipant via create_publisher() and create_datawriter(), and successively calling fastdds::dds::Publisher::delete_datawriter() to remove the datawriter, I always get the erroneous (annoying) warning when removing the first writer:

"Writer xx.xx.xx.xx.xx.xx.xx.xx.xx.xx.xx.xx|x.x.x.x not found.":

This log line seems to be triggered by the code in src/cpp/rtps/builtinliveliness/WLP.cpp, WLP::remove_local_writer(). Basically, the code is stuctured as follows:

bool WLP::remove_local_writer(RTPSWriter* W)
    [....]
    if (W->get_liveliness_kind() == AUTOMATIC_LIVELINESS_QOS)
    {
        [...]
    }
    else if (W->get_liveliness_kind() == MANUAL_BY_PARTICIPANT_LIVELINESS_QOS)
    {
        [...]
        return true;
    }
    else if (W->get_liveliness_kind() == MANUAL_BY_TOPIC_LIVELINESS_QOS)
    {
        [...]
        return true;
    }
    logWarning(RTPS_LIVELINESS, "Writer " << W->getGuid() << " not found.");
    return false;

A a first glance, it looks like the first if () block should also conclude with a "return true;". When debugging the code in the first (AUTOMATIC_LIVELINESS_QOS) block, the last writer being removed will use the code

if (automatic_writers_.size() == 0)
{
      automatic_liveliness_assertion_->cancel_timer();
      return true;
}

and thus not produce the log line that all previous removals do (the return false seems to be ignored on the way back up the stack).

The issue seems to happen on fastdds 2.3.2 on all windows and linux.

ma30002000 avatar Oct 06 '21 07:10 ma30002000

@ma30002000 Nice catch, I do think you're right!

Would you mind doing a PR with the fix? It would be great if it also includes a regression test here

MiguelCompany avatar Oct 06 '21 08:10 MiguelCompany

This was fixed by #2661 and its corresponding backports

MiguelCompany avatar Mar 28 '23 07:03 MiguelCompany