The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
This is ticketed at https://code.ros.org/trac/ros/ticket/3403. There I wrote:
I've noticed this issue with unsubscribe callbacks too. However, it's not true that they're never called; they do get called exactly 60s after you subscribe.
In practice this shouldn't normally be an issue. In each nodelet we use connect callbacks to control whether it hooks into a data source (camera or ROS topic). As long as it's getting data, it publishes some processed output. So if all subscribers to the output unsubscribe, the next call to publish() triggers the disconnect callback, which unhooks from the data source. So as long as you're streaming data, disconnects will be timely.
It's still annoying and can cause odd behavior in practice - e.g. if the register nodelet doesn't get the tf data it needs, it can't publish(), so it takes the full 60s to disconnect. So I'd like to see this fixed, or at least know why it happens.
Generally this hasn't been an issue for us - if we need the disconnect callback called immediately, it's because we're shutting down a publisher that's continuously spewing data. Do you have a use case where you require a timely disconnect callback for an inactive publisher?
| | 2 | No.2 Revision |
This is ticketed at https://code.ros.org/trac/ros/ticket/3403. https://code.ros.org/trac/ros/ticket/3403. There I wrote:
I've noticed this issue with unsubscribe callbacks too. However, it's not true that they're never called; they do get called exactly 60s after you subscribe.
In practice this shouldn't normally be an issue. In each nodelet we use connect callbacks to control whether it hooks into a data source (camera or ROS topic). As long as it's getting data, it publishes some processed output. So if all subscribers to the output unsubscribe, the next call to publish() triggers the disconnect callback, which unhooks from the data source. So as long as you're streaming data, disconnects will be timely.
It's still annoying and can cause odd behavior in practice - e.g. if the register nodelet doesn't get the tf data it needs, it can't publish(), so it takes the full 60s to disconnect. So I'd like to see this fixed, or at least know why it happens.
Generally this hasn't been an issue for us - if we need the disconnect callback called immediately, it's because we're shutting down a publisher that's continuously spewing data. Do you have a use case where you require a timely disconnect callback for an inactive publisher?
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
