there is some limitation on datareader nums

[Alexxxing]

Is there an already existing issue for this?

• 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

[Carlosespicur]

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)?

[Alexxxing]

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.

[Alexxxing]

Hi @Carlosespicur
Thanks for your replay, my problems was sloved after I update to 2.14.x

[Alexxxing]

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.