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
Reconnection issue #34
Comments
The code looks correct to me
If things aren't working as expected, please provide me a minimal example. Helps me fix faster :)
I'm really happy with the current design. Simple to maintain unlike the last one and easy to customize :) |
Thanks for the help, that explains not getting reconnection/disconnect notifications yet. I also tried switching to using I'm a bit swamped at the minute (as we all are), but I'll try and put together a minimal reproduction over the weekend. |
This is what I have to try and reproduce this so far. If I run the Mosquitto server using docker: docker run --rm -p 1883:1883 eclipse-mosquitto:latest And then run the reconnection example: cargo run --example reconnection I get the following output from the reconnection example when I stop the server to simulate disconnection:
Client is reconnecting successfully. If I then modify the reconnection example to connect to our production MQTT server (TLS + credentials) and disconnect the network to test disconnection I get the following:
I'm now getting the same error as my other application, although reconnection is still working which suggests I may be doing something else wrong. I tried to modify the reconnection example to be more similar to my application but this didn't change the behaviour (https://github.com/mojzu/rumq/blob/master/rumq-client/examples/reconnection.rs). When I get another chance I'll keep trying to modify the reconnection example until it either reproduces the error or shows me what I've done wrong in my application. |
You mean all the MVEs are working fine as expected? |
I feel like I'm in the same boat. |
"minimum" repro: use rumq_client::MqttOptions;
use rumq_client::QoS::AtLeastOnce;
use std::time::Duration;
use tokio::stream::StreamExt;
use tokio::sync::mpsc;
use tokio::time::delay_for;
#[tokio::main]
async fn main() {
let mut options = MqttOptions::new("Obama", "10.22.22.6", 1883);
options
.set_credentials("mqttuser", "mqttpass")
.set_keep_alive(5);
let (mut req_tx, req_rx) = mpsc::channel(10);
let mut eventloop = rumq_client::eventloop(options, req_rx);
loop {
let mut stream = eventloop.stream();
while let Some(notif) = stream.next().await {
println!("{:?}", notif);
use rumq_client::Notification as N;
use rumq_client::Request as R;
use rumq_client::{publish, subscribe};
let req = match notif {
N::Connected => Some(R::Subscribe(subscribe("in", AtLeastOnce))),
N::Publish(pubar) => Some(R::Publish(publish("out", AtLeastOnce, pubar.payload))),
_ => None,
};
if let Some(req) = req {
req_tx
.send(req)
.await
.expect("`requests` dropped by eventstream")
}
}
eprintln!("stream ended, retrying in 100ms");
delay_for(Duration::from_millis(100)).await;
}
} [package]
name = "min-example"
version = "0.1.0"
edition = "2018"
[dependencies]
rumq-client = "0.1.0-alpha.5"
tokio = {version = "0.2.11", features = ["stream", "macros", "sync"]} Output:
|
I've rebuilt my code with the branch from qm3ster and retested using our production MQTT server. I'm no longer getting the repeated "Error awaiting for last ping response" error and I'm getting new messages afterwards which suggests this issue is fixed! I think I was struggling to recreate it because I was testing with an MQTT server running on localhost and pretending to disconnect the network by stopping the server. I'm guessing this wasn't leading to dropped packets in the same way as when I did these tests over a network and physically removed the ethernet cable. |
Sorry for the delay. This will be fixed in the next few days |
@mojzu were you still getting some or all messages (together with the repeating error)? Or did this error completely block incoming in your case? |
It's just that the only branch that could reset |
I'll probably work on this after 2 days. One problem I see (and as @qm3ster rightly pointed out), I think reset should happen here |
Fixed in #42 |
I've upgraded to alpha.6 version and retested, and the issue is fixed. I did have a compilation error while upgrading of Thanks for the fix and again for the great library! 👍 |
Hi, I'm in the process of migrating from the rumqtt client to this library and running into reconnection problems during testing. When I disconnect the client from the network the broker is on I get the following error:
However when I reconnect the client to the network I continue getting the same error and the client doesn't reconnect. Based on the logs I'm not receiving a Reconnection or Disconnection notification, but with each error I am getting a StreamEnd:
In case I've done something wrong here is my code for setting up the client options.
And my code for spawning the tasks for sending/receiving.
If there's any other information I can provide let me know. Thanks for the help and the great library, migrating was much easier than I expected and the new interface works very well with my other async code 👍
The text was updated successfully, but these errors were encountered: