dashboard_client: Allow a larger timeout on initial connection #126
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Apparently, if we connect to the socket right after it became available, it can happen, that we don't get a "connected" message from the dashboard server in a second. This commit should not only increase the timeout on the initial read to a value that should be sufficient, but also establishes a retry with a warning output.
Codecov ReportBase: 51.21% // Head: 51.23% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #126 +/- ##
==========================================
+ Coverage 51.21% 51.23% +0.01%
==========================================
Files 82 82
Lines 2466 2471 +5
Branches 279 278 -1
==========================================
+ Hits 1263 1266 +3
- Misses 1072 1075 +3
+ Partials 131 130 -1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
urmahp
approved these changes
Nov 7, 2022
Contributor
urmahp
left a comment
urmahp
left a comment
There was a problem hiding this comment.
LGTM.
I have verified that it works with the increased timeout and that it doesn't work with the original timeout of 1 seconds when the robot simulator has just finished booting.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Apparently, if we connect to the socket right after it became available, it can happen, that we don't get a "connected" message from the dashboard server in a second.
I tested this with a retry timeout of 1ms here. Then, when launching the dashboard_client before starting URSim made the client trying to connect each millisecond. I read the
Connected: Universal Robots Dashboard Servermessage roughly 1.5 seconds after the lastFailed to connect to robot on IP...output. This seems to be the minimum time we need to wait for the bootup message after the socket has been opened (at least on my machine with URSim).Therefore, I set the timeout for the initial
readcall to 10 seconds and added a retry mechanism to that. I don't think this should happen which is why I added a warning output.