-
Notifications
You must be signed in to change notification settings - Fork 72
Handle messages asynchronously #71
Comments
@ivanovaleksey tokio2 branch is still in works (maybe it'll be ready in the next 10 days) but it's very ergonomic with handling incoming messages. you get all the incoming messages in a channel and you can handle it in a way that fits your needs. But it's your responsibility to pull the messages out of the channel at a rate greater than incoming messages or else the packets will be dropped. |
Thank you for the reply @tekjar. Does dropping messages occur on master branch? As I understand tokio2 will be merged into the master, so dropping will be on master anyway? |
@ivanovaleksey master branch uses threadpool to execute callbacks. I've not tested master enough with incoming messages to understand how threadpool behaves during high loads. If threadpool uses a unbuffered channel, the memory will just keep going up if the callbacks are heavy/blocking. One way to ensure that you don't drop messages in tokio2 is to not do heavy processing in the thread that receives data and offloading work to a threadpool. |
Yes, there is a threadpool on master branch but it has capacity of
Yes, that was my initial idea too. It doesn't have any impact on |
Yeah puback should be sent before handling the message, or else (most) brokers will keep resending the message if your callback is heavy |
Thanks once again @tekjar. |
The reason behind choosing a channel instead of callback is to give users the flexibility. These 'Receiver's are crossbeam-channels receivers which are very flexible. You can use these receivers in multiple threads to load balance or use a threadpool for other use cases. Thinking about this, may be I should provide a way to configure the size of the channel (or) use unbounded channels |
Hello @tekjar, again I have a question about async handling. Suppose I have thread pool with a size of 3. Is there any workaround here? Thank you. |
@ivanovaleksey If you are using tokio2 branch, you'll be able to clone |
Thanks @tekjar, I currently use |
Hello,
thank you for the great library!
I am looking for Rust MQTT library for my application.
I want it to be able to handle incoming messages asynchronously because there will be DB interaction and other blocking things.
I added
thread::sleep
withinon_message
callback.Message handling had been queued: one message was handling (i.e. waiting on
sleep
) and new incoming message was queued and processed only after awaking.Maybe that is totally my fault and I made the main and the only one thread to sleep.
What is the correct way to asynchronous message handling?
Can I create some kind of a thread poll within
on_message
and just push incoming messages to that pool?Or it will affect dealing with QoS?
As I can see from the code we firstly send
PUBACK
and then call user's callback.Does it mean that it doesn't matter whether I would handle incoming message in the same or in separate thread because
PUBACK
was already sent?Also, I have found tokio2 branch. Maybe it better suits for async handling?
Thank you.
The text was updated successfully, but these errors were encountered: