Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] wait_pdp_discovery should use the topology to wait for participant discovery. #8

Open
EduPonz opened this issue Dec 11, 2019 · 0 comments

Comments

@EduPonz
Copy link

EduPonz commented Dec 11, 2019

I all!

We have been using this tool to test the performance of Fast-RTPS for some time. Recently, Fast-RTPS has added a new feature which is a participant white-list, meaning that users can use the XML to set, for each participant, a list of participants that are "allowed" to be discovered. We believe that this feature really much applies to the benchmark case where the topology is known beforehand.

However, we have encountered a problem when using this participant white-listing, which is that we hit the assertion in performance_test::System::wait_pdp_discovery()

// check if maximum discovery time exceeded
auto t = std::chrono::high_resolution_clock::now();
auto duration =
        std::chrono::duration_cast<std::chrono::milliseconds>(t - pdp_start_time - max_pdp_time).count();
if (duration > 0){
        assert(0 && "[discovery] PDP took more than maximum discovery time");
}

The problem is that with the white-list, the nodes do not discover all the other nodes, but only they ones the are interested in. We have tackled this issue by avoiding to wait for participant discovery using PR #7, but we believe that a better approach would be to refactor performance_test::System::wait_pdp_discovery() so it uses the topology to check which participant has discovered which, returning when all the necessary connections are established.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant