A follow-up that surfaced while making GET /{apps}/{id}/status read from the lifecycle state.
Summary
Ros2LifecycleStateReader (src/ros2_medkit_gateway/src/ros2/status/ros2_lifecycle_state_reader.cpp) creates a new lifecycle_msgs/srv/GetState client on every status poll of a managed lifecycle node and destroys it when the call returns. Creating and destroying a service client churns DDS entities on each poll. For a status endpoint that is polled often this is avoidable overhead.
Proposed solution (optional)
Cache the GetState clients keyed by service path inside the reader, guarded by the existing mutex, so repeated polls of the same node reuse the client instead of creating and tearing one down each time. Drop or invalidate an entry when the node lifecycle services change or disappear. Behavior stays the same; this is a performance change only.
Additional context (optional)
Current behavior is correct, just not amortized. The per-call create already guards an empty path and is wrapped in try/catch, so caching is purely an optimization and is not required for correctness. Part of the lifecycle control work tracked in #207.
A follow-up that surfaced while making
GET /{apps}/{id}/statusread from the lifecycle state.Summary
Ros2LifecycleStateReader(src/ros2_medkit_gateway/src/ros2/status/ros2_lifecycle_state_reader.cpp) creates a newlifecycle_msgs/srv/GetStateclient on every status poll of a managed lifecycle node and destroys it when the call returns. Creating and destroying a service client churns DDS entities on each poll. For a status endpoint that is polled often this is avoidable overhead.Proposed solution (optional)
Cache the GetState clients keyed by service path inside the reader, guarded by the existing mutex, so repeated polls of the same node reuse the client instead of creating and tearing one down each time. Drop or invalidate an entry when the node lifecycle services change or disappear. Behavior stays the same; this is a performance change only.
Additional context (optional)
Current behavior is correct, just not amortized. The per-call create already guards an empty path and is wrapped in try/catch, so caching is purely an optimization and is not required for correctness. Part of the lifecycle control work tracked in #207.