Closed Tockra closed 3 years ago
I see they work just for the newest git version...
The Git sources are changing quickly at the moment in preparation for a new release. There will be several breaking changes in the v0.8 release. The samples may only work with the code from the specific branch. If they don't work within a branch, please let me know, so I can fix them before the release.
So I found a real bug now. https://github.com/eclipse/paho.mqtt.rust/blob/master/src/async_client.rs The reconnect part isn't correct. You need to subscribe the topics after reconnection again. Otherwise you get a connection but you don't get the messages anymore.
But for your information, the reconnect is realy slow. When I disable my wifi and enable it again. I need something between 20-60 seconds to reconnect to the mqtt broker.
No that's not a bug. Reconnect just makes a connection. If you're using a persistent (non-clean) session, the server will remember, not only your subscriptions, but also any QoS>0 messages that would have been sent to you while you were disconnected. This is a very important feature of MQTT. It might be worth reading through the MQTT spec or some tutorials. The protocol has a lot of useful features around connection and session management.
As for the slow reconnect, this is likely something that can be adjusted in your application to account for your particular network setup.
Is it taking a long time for the client to notice the connection is down? This often happens with wireless setups. Then maybe decrease your keep alive interval. That would help.
Are you using an example that has a retry backoff? When you have 100,000 devices in the field, you don't want them all calling back in the immediate second the connection to the server is restored, or wasting their own CPU in a fast retry cycle when the server is down. So some examples demonstrate that.
The best thing may be to check the logs or spy on the network traffic. That may give you some hints.
No that's not a bug.
Okay my fault. I wanted to link the example and not the async client: https://github.com/eclipse/paho.mqtt.rust/blob/master/examples/async_subscribe.rs Your example provides a subscriber which reconnects after network issue but doesn't subscribe the stream again? I think your example is missing a
println!("Subscribing to topics: {:?}", TOPICS);
cli.subscribe_many(TOPICS, QOS).await?;
after line 109.
Is it taking a long time for the client to notice the connection is down? This often happens with wireless setups. Then maybe decrease your keep alive interval. That would help.
No it recognize the failing connection within ~5 seconds. But the reconnect needs some time. I'm using your example: https://github.com/eclipse/paho.mqtt.rust/blob/master/examples/async_subscribe.rs I just changed it to use tokio. Not a own application.
I think your example is missing a
println!("Subscribing to topics: {:?}", TOPICS); cli.subscribe_many(TOPICS, QOS).await?;
after line 109.
Did you try it?
I think your example is missing a
println!("Subscribing to topics: {:?}", TOPICS); cli.subscribe_many(TOPICS, QOS).await?;
after line 109.
Did you try it?
Yes. Before I wrote my post. Without these lines it reconnects but doesn't get new messages. After adding this lines it worked.
Something must be wrong. The example connects with a persistent session:
let conn_opts = mqtt::ConnectOptionsBuilder::new()
.keep_alive_interval(Duration::from_secs(20))
.mqtt_version(mqtt::MQTT_VERSION_3_1_1)
.clean_session(false) <- Request persistent session
.will_message(lwt)
.finalize();
The broker should not only remember the subscriptions, but also queue up any messages with QoS>0 on those topics while you're client is disconnected.
So in other words, you should be able to disconnect your board (pull the network cable, turn off the WiFi, or whatever), then send a few more messages to the broker from another client that is still connected using QoS=1 or 2. When you turn the WiFi back on, your board should automatically reconnect and then receive the messages that were sent while your board was disconnected.
If you connect with a clean (non-persistent) session, then, yes, you need to re-subscribe to your topics to receive messages again.
In my test after reconnecting I didn't get the message of the topic which was subscribed. If you wanted to do that, then everything is right. But I think that isn't in the meaning of the example.
@fpagliughi Hi, I'm wondering when will be the next stable release? I just had a new project and I would definitely want to try new version of paho which has future0.3 support, if there is musl that's even better.
The new release was delayed because of my work schedule. But it was getting pretty close. You can definitely start testing the master branch in a new project. It has futures 0.3, but the musl support is not quite there yet,
In v0.8
Hi Guys,
I tried to compile 2 of your examples: https://github.com/eclipse/paho.mqtt.rust/blob/master/examples/ssl_publish.rs https://github.com/eclipse/paho.mqtt.rust/blob/master/examples/async_subscribe.rs
Here the compiler output: ssl-example:
async_output
I'm just raging. I just wanted to write fast a mqtt consumer and I'm trying to code it for 4 hours... Nothing works, everytime I get a error.
Please help me... T