You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Subscribing to the /parameter_events topic while using Discovery server shouldn't cause the CPU of the subscriber process to go 100%.
Current behavior
When subscribing to the /parameter_events topic in one node and launching a composable node container with few even very simple composable nodes (5-10), there is a significant spike of the CPU usage from around 0% to 100%.
The nodes need to be launched with the discovery server present, to observer the CPU spike
No significant spike when publishing from the cli
Launching the nodes in multiple separate processes doesn't cause the issue
If the simple node has the start_parameter_event_publisher(false) and start_parameter_services(false) options set, then there is no CPU spike
Steps to reproduce
Create a node with a subscriber to the /parameter_events
Is there an already existing issue for this?
Expected behavior
Subscribing to the
/parameter_events
topic while using Discovery server shouldn't cause the CPU of the subscriber process to go 100%.Current behavior
When subscribing to the
/parameter_events
topic in one node and launching a composable node container with few even very simple composable nodes (5-10), there is a significant spike of the CPU usage from around 0% to 100%.start_parameter_event_publisher(false)
andstart_parameter_services(false)
options set, then there is no CPU spikeSteps to reproduce
/parameter_events
Fast DDS version/commit
Fast DDS: ros-humble-fastrtps: 2.6.6-1jammy.20230919.195605
Discovery server: fastdds-tools: 2.5.0+ds-3
Platform/Architecture
Other. Please specify in Additional context section.
Transport layer
Default configuration, UDPv4 & SHM
Additional context
Ubuntu 22.04
ROS2 Humble
The discovery server and the ros2 application running in two separate docker containers
XML configuration file
Relevant log output
No response
Network traffic capture
No response
The text was updated successfully, but these errors were encountered: