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

Fix QoS depth settings for clients/service ignored #340

Merged
merged 1 commit into from
Oct 12, 2021

Conversation

iuhilnehc-ynos
Copy link

to fix ros2/rclcpp#1785

Signed-off-by: Chen Lihui lihui.chen@sony.com

Signed-off-by: Chen Lihui <lihui.chen@sony.com>
Copy link
Contributor

@fujitatomoya fujitatomoya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@fujitatomoya
Copy link
Contributor

@ros-pull-request-builder retest this please

Copy link
Collaborator

@eboasson eboasson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know I suggested simply deleting these lines, and it does indeed prevent the QoS settings from being ignored. However, on consideration that's not the same as the defaults used for "regular" readers and writers also being appropriate for clients and services.

With this PR, providing a QoS profile with RMW_QOS_POLICY_HISTORY_SYSTEM_DEFAULT and RMW_QOS_POLICY_DEPTH_SYSTEM_DEFAULT will result in KEEP_LAST with depth 1. There doesn't seem to be any specification of what one should expect if QoS's are set to "default" in the ROS 2 QoS profile and therefore it can be considered the correct result given that the user is not entitled to any expectation. In all likelihood, this setting will result in a system that usually works fine — which, in my experience, is not good enough.

I do want to point out that it is, essentially, in line with rmw_qos_profile_services_default. Therefore, arguably, in ROS 2, KEEP_LAST for service invocation is considered the proper setting. In my view, this choice means an application should expect failure to receive a response without any indication, or the system (of which the application is part) be designed in such a way that the limited history depth cannot cause a problem.

I am approving this PR because I assume that I am just stating the obvious in this review comment and that default to KEEP_LAST with depth 1 is indeed the intent.

@fujitatomoya
Copy link
Contributor

CI:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

@fujitatomoya
Copy link
Contributor

CI failure is unrelated. (see also ros2/rmw_fastrtps#564 (comment))

@fujitatomoya
Copy link
Contributor

@clalancette @ivanpauno @eboasson we do not have access for this repository, could you do us a favor?

@eboasson
Copy link
Collaborator

@fujitatomoya sorry for waiting a bit. I was hoping to get a confirmation that this is really the intent despite my concerns about the wisdom of the defaults, but that's really not a good reason to delay this PR!

@eboasson eboasson merged commit d209f65 into ros2:master Oct 12, 2021
@fujitatomoya
Copy link
Contributor

@eboasson i understand it is always nice to check ❗ thanks for the support.

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

Successfully merging this pull request may close these issues.

QoS depth settings for clients/service ignored
3 participants