-
Notifications
You must be signed in to change notification settings - Fork 102
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
.unwrap() inside the library causes whole program to crash #152
Comments
Yeah, none of that is good! First, the unwrap() on the channel send doesn't belong there. That will crash out any time the application drops the receiver. It should probably ignore the error. But really the app should stop consuming when it drops the receiver. I still need to implement This should probably happen automatically. Maybe instead of a raw channel Receiver, the But.... I'm not seeing where the receiver is being dropped in your code snippet. I'll have to test it out. The purpose of the double option channel was so that the receiver could be held during disconnects and continue when the connection was re-established. And all of this wouldn't have been necessary if the auto-reconnect worked. I did receive a report that reconnect didn't work if it was down for a while (15-20 min sounds familiar!) I have a vague memory of suspecting the SSL/TLS layer. Can you share your create & connect options? (Omit any user names, passwords, private URLs, etc, but show if you're using them) Also, what platform are you using? Linux/Windows/Mac, etc |
It does get dropped, seems like I skipped including that part. Also I think this happened when I run two instances of the program by mistake, and since they had same client id, they kept disconnecting each other so consumer just dropped over and over again in short period of time. Here is the full snippet:
On reconnect, I just re-subscribe and start consuming again. Maybe I shouldn't? And I've just realized, if client disconnect between reconnect and subscribe, this might get me into an infinite loop. I guess I should add another reconnect logic there (if subscribe_many returns an error).
Broker (mosquitto) runs on a Raspberry Pi on my local network, there is no TLS. I'm using Linux (Ubuntu) and connect as following:
|
Cool. Thanks for the additional information. What I meant with "I don't see rx being dropped", was that the receiver loop should not exit just because the connection closes:
The receiver's iterator should only exit from the loop when the transmitter is closed, but the transmitter is still there and gets an error when it tried to send a message to the receiver which has closed. So, somehow, the rx loop exited, rx went out of scope, and then a message arrived. |
I'mg going to push a commit today that will at least prevent the program from exiting if this happens. Instead, it will log the error and keep running. In addition, the commit contains new code to stop consuming (or streaming if you're using async/await), and functions to remove callbacks. If you were to call If that all looks good, I'll move on to trying to figure out why the auto-reconnect wan't working. But the new Rust release will also sit atop the new C v1.3.10 release, so that's bringing in a few bug fixes. |
Thank you! |
… comsuming/streaming and to remove callbacks.
OK. I pushed an intermediate fix to master. It will, at least, not panic if the receiver disappears while the consumer is still running. There is also the new To test that, I added a Ctrl-C handler to the paho.mqtt.rust/examples/sync_consume.rs Lines 138 to 156 in dc061e1
|
The fix for the crash (remove the |
I've just realized, there is a break after reconnect. It breaks out of |
From what you posted, it appears that the In some of the examples, I do use a break to get out of the The code is a little obfuscated. It could be like:
|
What I meant was there were 2 breaks in the original code, I missed the one while re-typing here. More specifically there is a function called "block_until_reconnect()" which looks like this:
And original loop looks like this
I merged them for sake of brevity but missed that part. Sorry about that. |
Oh, OK. Great; thanks for letting me know so I didn’t waste time chasing a ghost bug. Next I’ll start testing issues with auto reconnect. |
The partial fix went out with v0.11.0. I'm going to close this and open a new issue concerning auto-reconnect. |
Hi,
Initially I used auto_reconnect in connection options with (inital_wait = 1, max_wait = 5) but when I disconnected from WiFi for 15-20 mins and reconnected, I didn't received new messages in following code.
Note: I'm using sync client.
Then I disabled auto reconnect and changed the code as following:
Host that is running the MQTT broker was under load and my client disconnected and connected few times, then crashed on "unwrap" call at async_client.rs, line 1022. At
tx.send(msg).unwrap();
Here is the stacktrace:
The text was updated successfully, but these errors were encountered: