Publish from MessageReceivedHandler doesn't work
See original GitHub issueWhen I Publish message from handler
client.UseApplicationMessageReceivedHandler(async e => { await client.PublishAsync(message); });
I am getting MqttCommunicationTimedOutException from MqttPacketAwaiter before receiving acknowledgement that message was Published.
Despite I have set very long communication timeout - it is throwed much earlier. I am using QOS 1.
Workaround that we’ve currently decided to use - to publish asynchronously:
client.UseApplicationMessageReceivedHandler(e => { Task.Run(async () => await client.PublishAsync(message)); });
Issue Analytics
- State:
- Created 4 years ago
- Comments:14 (5 by maintainers)
Top Results From Across the Web
Publish from MessageReceivedHandler doesn't work #648
When I Publish message from handler. client.UseApplicationMessageReceivedHandler(async e => { await client.PublishAsync(message); });.
Read more >Android Handler doesn't handle messages
So I've decided I'm going to use the Main Looper message pool to manage the Handler, and then have the Handler manage a...
Read more >Kinetic Message Handler works in preview but not when ...
When I preview this it works flawlessly. When I publish and then run it I get “Customer Comment” in the message area of...
Read more >NServiceBus can't find handlers on the host that is ...
This all works fine, however, NServiceBus is complaining that there are no handlers for said event and is going to retry it three...
Read more >Publish failure event when a message is moved to the error ...
What I would like to achieve is for a failed handler to publish an event prior to the message being sent to the...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

You can use a second client if that is OK in your UseCase (new connection, new client ID etc.). The problem is that there are different use cases out there. If you specify that a message is only processed successfully if a another message was delivered (including ACK) then there is a dead lock.
I personally have a separate queue in my apps (BlockingCollection) and a different worker thread. So I am never blocked but I always send ACK even if the real operation was not performed yet. To detect that I have some more topics or payloads which contain some custom data which indicates a success.
I also thought about adding an internal queue for PUBLISH packets so that other packages like some ACK will be still processed but the problem is that this queue will grow and grow and maybe the receive speed is higher than processing speed so that the queue will grow forever. Adding a limit for that queue may lead to the same dead lock at some point.
From MQTT spec:
It just mentioned “ownership”. So it does not include a full blown business logic. This makes sense to me because we are talking about a telemetry transport protocol only. Not a full blown RPC protocol like SOAP etc.