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

Delay unregister to mitigate !138 #247

Merged
merged 6 commits into from
Feb 8, 2017
Merged

Conversation

v-lopez
Copy link
Contributor

@v-lopez v-lopez commented Jan 12, 2017

No description provided.

@T045T
Copy link
Contributor

T045T commented Feb 5, 2017

Looks like some tests are failing because they expect deregistration to be instant - can you take a look at those and fix them, please?

@v-lopez
Copy link
Contributor Author

v-lopez commented Feb 6, 2017

@T045T I have modified the tests. Due to the nature of the changes I have added to add sleeps matching the duration of the unregister timeout (currently 10seconds) so the tests need 2-3 minutes to run instead of 1. If that is a problem, the duration of the timeout can be reduced on the unit tests, but I'd rather test the code without any modifications.

@T045T
Copy link
Contributor

T045T commented Feb 6, 2017

Thanks!
I think it's fine to set unregister_timeout to something smaller for testing, rather than triple the test execution time.
One more thing: Since it's a member now, can you change UNREGISTER_TIMEOUT to not be all caps?

@v-lopez
Copy link
Contributor Author

v-lopez commented Feb 6, 2017

Sure if we're not going to treat it as a constant either it's fine.

Tests will sleep for 10% extra of the timeout to prevent some situations
were the test sleep ended right before the unregister timer fired
@T045T
Copy link
Contributor

T045T commented Feb 6, 2017

Class-level constants are somewhat unusual, so I'd prefer to either make it a class member (-> lowercase name) or a module constant ( -> uppercase name). In the latter case, it's still possible to access (and modify) it from test code (looks like that was the reason you changed it into a member in the first place).

Since we don't really expect users to mess with it, a module constant is probably the way to go.

@T045T T045T merged commit a7a2e1a into RobotWebTools:develop Feb 8, 2017
@T045T
Copy link
Contributor

T045T commented Feb 8, 2017

Great work, thank you!

jorgenfb added a commit to jorgenfb/rosbridge_suite that referenced this pull request Feb 8, 2018
Pull request RobotWebTools#247 introduces a 10 second delay to mitigate issue RobotWebTools#138.
This change makes this delay configurable by passing an argument either
on the command line or when including a launch file.

Usage example:
```xml
<launch>
  <include file="$(find rosbridge_server)/launch/rosbridge_websocket.launch">
    <arg name="unregister_timeout" value="5.0"/>
  </include>
</launch>
```

Closes RobotWebTools#320
jihoonl pushed a commit that referenced this pull request Feb 24, 2018
Pull request #247 introduces a 10 second delay to mitigate issue #138.
This change makes this delay configurable by passing an argument either
on the command line or when including a launch file.

Usage example:
```xml
<launch>
  <include file="$(find rosbridge_server)/launch/rosbridge_websocket.launch">
    <arg name="unregister_timeout" value="5.0"/>
  </include>
</launch>
```

Closes #320
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.

2 participants