Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Fixes for services playback per review 2 #6
Fixes for services playback per review 2 #6
Changes from 5 commits
bc4d118
5f324c1
6397df6
94d418f
00bff3e
05a3d1d
9d98b04
b7116b9
b87c944
bede854
c5f6c13
a623a23
091620c
3c19873
98c14ef
f270ac1
974d687
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It appears to overlook the scenario where both the service and the client enable introspection contents for the same client ID.
Old function is PlayerServiceClient::is_include_request_message().
Except checking if request is included, this function also includes the following logic
Decide whether the request comes from the service or the client is used for one client ID. (Currently, it is decided by the first message including the request data. e.g. First message with request from client. We will use message from client to send request, even if message from service also provide request data.)
Consider the case. Service/client switched introspection type from metadata to contents in recorded data.
I don't consider the case. Service/Client switched introspection type from contents to metadata in record data, which leads that the decision in 1 maybe adjusted.
rosbag2/rosbag2_transport/src/rosbag2_transport/player_service_client.cpp
Lines 55 to 159 in a8312de
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Barry-Xu-2018 Thanks for finding and pointing out this. It seems I overlook these cases.
From one side I understand that it would be nice to have some autodetection algorithm to be able to decide whether to use a service request from the original client request or from the service request confirmation event message.
However, this sophisticated logic could have corner cases and would be difficult to understand or explain for final users.
In addition, it seems the original implementation with a "hidden" autodetection algorithm from the
PlayerServiceClient::is_include_request_message()
is not going to work due to the found issue on the RMW layer [service introspection event does not have unique GID during transactionros2#357](ros2/rmw#357).
I am more inclined to implement a simple logic for a while to allow publish service requests upon a boolean flag by client request or by service confirmation and add this flag to the settings and perhaps to the CLI or env variable. Need to figure out what is better on the current stage.
Also, I think that we need to publish original service events in all other cases to be able to see them in the
topic echo
during playback or other introspection tools.cc: @fujitatomoya
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that sounds reasonable to me as well. in default, we could rely the service events on service server side. i think this is easier and suggested way to use, but not always we can do this with 3rd party components.
I really do not see the benefit for this, can you share the use case for this?
i would do,
ros2 bag play --service
and enable introspection on server application to see the service server is working okay withros2 service echo
. if we publish all the service events on the topic at the same time during playback, thatros2 service echo
would be really complicated and printing duplicated messages?or are you suggesting that we would want to publish the service events with topic via specific option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MichaelOrlov
Yes. Since users are not aware of the internal selection logic, it can lead to confusion about the result under certain scenario.
I also agree with using simpler logic. However, this might result in losing support for complex scenarios, such as some services enabling introspection while others have client introspection enabled. It would require users to uniformly use either service introspection or client introspection.
I incline to add new option for play.
e.g.
--service-request-from {service, client}.
service
is default value.If there's a need to add automatic selection in the future (This depends on whether there is a demand from the users.), we can add an "auto" option.
Are you saying that users, besides being able to replay service requests, can also replay the service event topic like a normal topic, allowing other introspection tools to analyze recorded the information via service event topic?
If yes, enable this function, is there a new parameter for play (if this parameter exists, play service event topic instead of play service request) ? About filter parameters (--services, --exclude-services, etc), do they work? Or user should use --topics, --exclude-topics since service event topic is replayed as normal topic.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After checking current code,
--services
and--exclude-services
should still function normally, affecting the playback of service events.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Barry-Xu-2018 Ok I've cherry-picked (d6db1bb to support
--publish-service-requests
) and made some fixes above it. See my new commits on this branch.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MichaelOrlov
I updated test code based on latest code. Please refer to e096323.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Barry-Xu-2018 Thanks for updating tests in the e096323 I will review your changes at my Thursday morning or first half of the day.
Meanwhile could you please review my changes per this PR one more time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Barry-Xu-2018 I've cherry-picked your changes in tests from e096323. Honestly, didn't have time to review thoroughly, but this shouldn't be a problem.
If you don't have any more comments/requests for changes for This PR let's move forward and merge rhi PR to your branch.
I think we almost good to go. Will need to rebase and run CI after merge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some nitpick in mind to fix - but we can do it after code freeze