How to detect disconnected subscriber? #357
Description
Is there a way to detect a reconnecting subscriber on the publisher side? or detecting a disconnected subscriber and remove it?
When using reliable writer QoS and wait_for_acknowledgements, wait_for_acknowledgements always returns Timeout error if my subscriber process has restarted.
The logs from publisher process:
cargo run --example publisher
waiting for subscriber...
PublicationMatchedStatus { total_count: 1, total_count_change: 1, last_subscription_handle: InstanceHandle([192, 168, 1, 9, 18, 92, 0, 0, 0, 0, 0, 0, 0, 0, 0, 7]), current_count: 1, current_count_change: 1 }
found subscriber
PublicationMatchedStatus { total_count: 2, total_count_change: 1, last_subscription_handle: InstanceHandle([192, 168, 1, 9, 36, 92, 0, 0, 0, 0, 0, 0, 0, 0, 0, 7]), current_count: 2, current_count_change: 1 }
PublicationMatchedStatus { total_count: 3, total_count_change: 1, last_subscription_handle: InstanceHandle([172, 17, 0, 1, 55, 92, 0, 0, 0, 0, 0, 0, 0, 0, 0, 7]), current_count: 3, current_count_change: 1 }
thread 'main' panicked at dds/examples/publisher.rs:126:14:
called `Result::unwrap()` on an `Err` value: Timeout
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
The logs from subscriber process:
cargo run --example subscriber
Received: Command { robot_id: 0, speed: 100, direction: Left }
^C
cargo run --example subscriber
Received: Command { robot_id: 0, speed: 100, direction: Left }
^C
cargo run --example subscriber
Received: Command { robot_id: 0, speed: 100, direction: Left }
^C
Checking PublicationMatchedStatus, it seems each subscriber run has a new instance handle so the publisher fails to identify it as the same subscriber, also the publication doesn't seem to receive PublicationMatchedStatus when the subscriber is killed, and the subscriber is not removed from the publisher.
Metadata
Metadata
Assignees
Labels
No labels