You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a subscriber becomes unresponsive, the Publisher should still send messages to the other subscribers. That would be consistent with the behavior of roscpp.
Actual behavior
All subscribers stop receiving messages when one of them hangs.
Minimum example for a rust publisher:
rosrust::rosmsg_include!( std_msgs/String);use std_msgs::String;fnmain(){
rosrust::init("spammer");let publisher = rosrust::publish("/chatter",10).unwrap();letmut counter = 0;while rosrust::is_ok(){
publisher.send(String{data:format!("Large amounts of data, culminating in this incrementing counter: {}", counter)}).unwrap();
counter += 1;
rosrust::sleep(rosrust::Duration::from_nanos(1_000_000));}}
Then, open two more shells and run rostopic echo /chatter in both. Press Ctrl+Z in the second one to halt it. After a while (~30s on my machine), the other rostopic echo /chatter will stop receiving messages as well. Run fg in the shell where you did Ctrl+Z before. The messages now resume in both, with the first one skipping over the messages that were "lost" while the other was blocked.
What should happen instead
Only the hanging subscriber should skip messages. The other one should be receiving all messages with no interruption. That would be consistent with roscpp (you can check this behavior by running rosbag play on a bagfile and two rostopic echo clients, as in the example above).
The text was updated successfully, but these errors were encountered:
Expected behavior
Publisher
should still send messages to the other subscribers. That would be consistent with the behavior of roscpp.Actual behavior
Minimum example for a rust publisher:
Then, open two more shells and run
rostopic echo /chatter
in both. Press Ctrl+Z in the second one to halt it. After a while (~30s on my machine), the otherrostopic echo /chatter
will stop receiving messages as well. Runfg
in the shell where you did Ctrl+Z before. The messages now resume in both, with the first one skipping over the messages that were "lost" while the other was blocked.What should happen instead
rostopic echo
clients, as in the example above).The text was updated successfully, but these errors were encountered: