Unable to poll MQTTv5 event loop

[ctron]

It looks like it is not possible to poll on an MQTT v5 event loop. Instead of returning an Event, the loop returns ():

https://github.com/bytebeamio/rumqtt/blob/18c56c13c4a56ffcdb3a195806a311523856f925/rumqttc/src/v5/eventloop.rs#L116-L134

Maybe this is supposed to work differently to the MQTT v3.1.1 client. Or something is still missing.

[tekjar]

@ctron Trying out a different abstraction here. While I like poll abstraction because of the control I get, it has 2 foot guns

1. Users should always (manually) run eventloop.poll in a loop or nothing will work
2. Because eventloop.poll is also used for receiving incoming events, users sometimes tend to do calls that might block the eventloop or cause deadlocks

(eg. running client.subscribe after reconnection event is returned by poll. If client queue is already full, this will lead to deadlock)

In the new design, I'm favouring more towards spawning a background thread which polls the eventloop and sends events to the user. Suggestions are obviously welcome :)

[ctron]

Hm ok. Is there an example on how this works?

I must say, I did like the idea of polling. But I also wasn't aware of the subscribe issue you mentioned.

Maybe there is a mix of both approaches. Having some kind of event stream, which the user can poll to get notified. But which is fed by another internal loop, which knows what it is doing :)

[svet-b]

Would also love some more detail on the intended functionality of the v5 event loop.

A bit of context on my simple use case: I want to publish a few messages with QoS 1, collect the PubAcks to ensure the messages were published successfully, and disconnect.

In the v3.1.1 implementation the published message IDs are not available (https://github.com/bytebeamio/rumqtt/issues/349), so I can't do any matching on the PubAcks (I suppose I could count them and make sure I get the expected number, but that doesn't seem great). So I switched to v5 and now I can get the message IDs. But - using the same pattern as in the v3 example - now the notifications yielded by connection.iter().enumerate() are plain Ok(())s rather than actual Event structs (i.e. https://github.com/bytebeamio/rumqtt/blob/main/rumqttc/src/eventloop.rs#L138 vs https://github.com/bytebeamio/rumqtt/blob/main/rumqttc/src/v5/eventloop.rs#L152). So I don't know whether I'm getting PubAcks or something else (let alone the message IDs that are being acknowledged).

What's the right way to approach this? Should I be polling the event loop in some other way? Or do I just need to wait for either https://github.com/bytebeamio/rumqtt/issues/349 to be closed or for event notifications to be implemented (maybe an extended version of https://github.com/bytebeamio/rumqtt/issues/459).

By the way thanks for a great library!

[SirVer]

@ctron Is https://github.com/bytebeamio/rumqtt/issues/430 what you had in mind for this?

[ctron]

@ctron Is #430 what you had in mind for this?

Can I use it the same way with MQTTv3? Then I think the answer is yes.

[SirVer]

@ctron It was implemented for v3 in https://github.com/bytebeamio/rumqtt/pull/458, however it still has a bug which is worked through in #467

[swanandx]

is this issue resolved @SirVer @ctron ? if yes, can we close it?

[ctron]

I am not sure and I won't be able to test it in the near future. So from my side, feel free to close it.