eProsima
there is some limitation on datareader nums
Is there an already existing issue for this?
- [x] I have searched the existing issues
Expected behavior
I want to run well in EDP stage without datareader limit
Current behavior
In FastDDS version 2.3.0, there is an issue where a single participant in a process can only create and maintain up to a certain number of DataReaders simultaneously. When exceeding this number (which may be related to operating system performance, such as CPU core count), sporadic failures to send EDP messages occur during communication with other DDS protocols like RTI.
Steps to reproduce
create over 30 datareaders in a participant, there are something wrong to connect with others in EDP stage
Fast DDS version/commit
V2.14.x
Platform/Architecture
Windows 10 Visual Studio 2019
Transport layer
UDPv4
Additional context
No response
XML configuration file
<?xml version="1.0" encoding="UTF-8" ?>
<dds xmlns="http://www.eprosima.com">
<profiles>
<transport_descriptors>
<transport_descriptor>
<transport_id>my_udpv4_transport</transport_id>
<type>UDPv4</type>
<maxMessageSize>1450</maxMessageSize>
<interfaceWhiteList>
<address>10.0.0.1</address>
</interfaceWhiteList>
</transport_descriptor>
</transport_descriptors>
<participant profile_name="0_profile_name">
<domainId>0</domainId>
<rtps>
<defaultUnicastLocatorList>
<locator>
<udpv4>
<address>10.0.0.1</address>
<port>10802</port>
</udpv4>
</locator>
</defaultUnicastLocatorList>
<builtin>
<metatrafficUnicastLocatorList>
<locator>
<udpv4>
<address>10.0.0.1</address>
<port>10210</port>
</udpv4>
</locator>
</metatrafficUnicastLocatorList>
<metatrafficMulticastLocatorList>
<locator>
<udpv4>
<address>239.255.0.1</address>
<port>10200</port>
</udpv4>
</locator>
</metatrafficMulticastLocatorList>
</builtin>
<allocation>
<remote_locators>
<max_unicast_locators>4</max_unicast_locators> <!-- uint32 -->
<max_multicast_locators>1</max_multicast_locators> <!-- uint32 -->
</remote_locators>
<total_participants>
<initial>0</initial>
<maximum>0</maximum>
<increment>1</increment>
</total_participants>
<total_readers>
<initial>0</initial>
<maximum>0</maximum>
<increment>1</increment>
</total_readers>
<total_writers>
<initial>0</initial>
<maximum>0</maximum>
<increment>1</increment>
</total_writers>
<max_partitions>256</max_partitions>
<max_user_data>256</max_user_data>
<max_properties>512</max_properties>
<send_buffers>
<preallocated_number>127</preallocated_number>
<dynamic>true</dynamic>
</send_buffers>
</allocation>
<userTransports>
<transport_id>my_udpv4_transport</transport_id>
</userTransports>
<useBuiltinTransports>false</useBuiltinTransports>
</rtps>
</participant>
<participant profile_name="2_profile_name">
<domainId>2</domainId>
<rtps>
<defaultUnicastLocatorList>
<locator>
<udpv4>
<address>10.0.0.1</address>
<port>10802</port>
</udpv4>
</locator>
</defaultUnicastLocatorList>
<builtin>
<metatrafficUnicastLocatorList>
<locator>
<udpv4>
<address>10.0.0.1</address>
<port>10210</port>
</udpv4>
</locator>
</metatrafficUnicastLocatorList>
<metatrafficMulticastLocatorList>
<locator>
<udpv4>
<address>239.255.0.1</address>
<port>10200</port>
</udpv4>
</locator>
</metatrafficMulticastLocatorList>
</builtin>
<userTransports>
<transport_id>my_udpv4_transport</transport_id>
</userTransports>
<useBuiltinTransports>false</useBuiltinTransports>
</rtps>
</participant>
</profiles>
</dds>
Relevant log output
Network traffic capture
No response
Hi @Alexxxing, Thank you for the contribution. Version 2.3.0 is EOL, could you check whether this reproduces in any of the supported branches (2.14.x, 3.2.x)?
Hi @Alexxxing, Thank you for the contribution. Version 2.3.0 is EOL, could you check whether this reproduces in any of the supported branches (2.14.x, 3.2.x)? I get some trouble in 2.14.x, I can't find the serialize method for the union structure in the source code generated by the new version of fastddsgen.
Hi @Carlosespicur Thanks for your replay, my problems was sloved after I update to 2.14.x
however, i found there is still some limitation on datareader. After starting more than 8 FastDDS processes (each process uses the same domain ID and different participants), newly started processes cannot communicate normally. Specifically, writing data returns "success", but the data is not actually written. The task sample returns a code of 11. When the previously started FastDDS processes are closed, the subsequent processes can work normally.