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

Long/random time period before published messages arrive #239

Closed
follesoe opened this issue Oct 20, 2016 · 12 comments
Closed

Long/random time period before published messages arrive #239

follesoe opened this issue Oct 20, 2016 · 12 comments
Labels

Comments

@follesoe
Copy link

If my rosbridge client reconnects and starts publishing messages to a topic, it takes a random amount of time before the messages suddenly start appearing.

We test this by using rostopic echo /my_topic, and observe that the messages are arriving. Then we refresh the web client, which creates a new connection and start publishing messages to the same topic. The amount of time it takes from the client starts publishing messages and the echo-command displaying them seams a bit random. From a couple of seconds up to 30-40 seconds (and sometimes even more).

If we look at the diagnostics, rosbridge is outputting messages saying that the connection is open - so the web socket connection is established, and the client is publishing messages.

Any tips on how to debug/configure/fix this?

@kjeremy
Copy link

kjeremy commented Jan 13, 2017

I'm seeing this too with the node example.

@robobit
Copy link

robobit commented Mar 16, 2017

Same problem here, any progress or ideas how to troubleshoot it?

@kjeremy
Copy link

kjeremy commented Mar 16, 2017

This basically makes this project unusable.

@T045T
Copy link
Contributor

T045T commented Mar 17, 2017

I just tried to reproduce this with the latest version of rosbridge and did not experience any problems.

I think this might be related to #138 and thus should be fixed with #247 - can you report back on whether your use cases still break?

@kjeremy
Copy link

kjeremy commented Mar 18, 2017 via email

@ablakey
Copy link
Contributor

ablakey commented Mar 18, 2017

My understanding is that they don't get built as regularly, so if you want the latest package, you'll need to clone it and build from source.

http://wiki.ros.org/catkin/Tutorials/using_a_workspace

@T045T
Copy link
Contributor

T045T commented Mar 18, 2017

Looks like the latest releases for Indigo and Jade are pretty old by now so yes, building from source is your safest bet, and should be fairly straightforward - just don't forget to use rosdep to install all system dependencies :)

@kjeremy
Copy link

kjeremy commented Mar 21, 2017

It seems to work on the latest.

@robobit
Copy link

robobit commented Mar 31, 2017

I've build the latest version from source on 16.04/Kinetic but this doesn't seem to fix it for me.

@T045T
Copy link
Contributor

T045T commented Mar 31, 2017

Can you share a self-contained test case that reliably fails? I tried, and couldn't create one :/

@sjlevine
Copy link

Hello! Thanks for your work on the timeout, @T045T -- that has helped a lot when a client disconnects / reconnects quickly (such as when refreshing a webpage). Super useful!

For our use case, sometimes a client that's publishing data to the websocket server goes down for more than 10 seconds (i.e., when we're fixing bugs in our code 😄), after which we restart it. Unsurprisingly, we get the warning error about inbound TCP connections, and then a moderate, random wait until other long-running ROS nodes are able to access to the published data (such as rostopic echo).

I could of course make the timeout longer, or disable unsubscribing all together. I was curious if anyone has also found any other solutions though?

Thanks!

@github-actions
Copy link

This issue has been marked as stale because it has been open for 180 days with no activity. Please remove the stale label or add a comment to keep it open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants