Async callbacks are problematic when receiving ordered messages about mqtt-hs

[dustin]

I've added a bit of testing for this in my mqttd and also added support for my mqtt-bridge project. Running a large bridge with ordered messages greatly reduces throughput, but it's pretty clear.

(of course, it supports both ordered and unordered sources so you can have both high throughput and enforced ordering where necessary)

[dustin]

That's reasonable. I think it used to matter a lot more in a previous design. I'm certain I rely on this behavior in a few apps, but if I can push that behavior into my app, it might not be too bad. The remaining tricky part is having callbacks not wreck the whole system.

[kamek-pf]

I also observed this behavior in some parts of our code base where ordering is required.
I haven't found another Haskell MQTT client, so I think there's no good solution to this problem currently.

[dustin]

Thanks for the input. I don't currently have any cases where ordering is required, but it makes sense. I don't know how deep the assumptions are anymore, but it should be possible to enforce some ordering.

…

On Thu, Apr 29, 2021, 14:19 Bertrand Bousquet ***@***.***> wrote: I also observed this behavior in some parts of our code base where ordering is required. I haven't found another Haskell MQTT client, so I think there's no good solution to this problem currently. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAN43SGU47L4MOWTDCNHDTLHENVANCNFSM4SGWZ7ZQ> .

[kamek-pf]

I have a possible implementation for this in #25.

[dustin]

Thanks a lot for working on this. I'm pushing the current change. I'll tinker around with it a bit and also see if I can get some tests in https://github.com/dustin/mqttd that exercise the code and push out a new release.