MQTTnet
MQTTnet copied to clipboard
dotnet
ManagedMqttClient
PublishAsync is now EnqueueAsync, but while PublishAsync used to accept a cancellation token, EnqueueAsync does not. I've had cases where PublishAsync used to get stuck, so I used to cancel it after 7 seconds. Should we use something like this?
var ct = new CancellationTokenSource(TimeSpan.FromSeconds(7)).Token;
await client.EnqueueAsync(message).WaitAsync(ct).ConfigureAwait(false);
The method is now renamed because it never published anything in the past. This was misleading. It just puts the message into an internal queue and it is being published later (when the managed client is connected etc.). So now there is no need to have a cancellation token because where is no network access etc. at all.
Are you able to reproduce these stucked called. If so there might be another issue.
I have code publishing every 10 seconds running 24/7 for years. Years ago I used to have it hang on me and I'd have to restart the app. One day I used the CancelAfterAsync code from https://stackoverflow.com/a/57994553/9945524 to cancel via the cancellationtoken if 7 seconds expire trying to do the PublishAsync. Since I did that, the code didn't hang once, and years went past.
Now I upgraded to the latest major build, and I couldn't use CancelAfterAsync anymore since EnqueueAsync doesn't have a cancellationtoken. So I thought let me try without it, so I did, but few hours later the app stopped publishing. So now I've used the WaitAsync functionality of .NET 6 now on the EnqueueAsync methods and so far it hasn't gotten stuck.
Could it be because the BlockingQueue is getting deadlocked? Perhaps have an asynchronous alternative for it? https://stackoverflow.com/a/21225922/9945524
Also if this helps, it only happens on an assembly hosted on a Raspberry Pi with a very weak WiFi connection. I have code that's publishing that's on the same MQTT server which has never had this problem.
This is indeed something I read a couple of times now. I will have a look if there is a possible dead lock in the managed client. Are you able to use the regular client instead? It should not have this issue.
I now have also the problem that the EnqueueAsync is not returning. Is there a way to further analyse why that problem does exist?
When i run the software on my laptop it works fine. But on a Win 10 running on an WinIOT Device is blocking every enqueueAsync after a successfull publish.
I would love to help analyse the problem, because i really need the managed client functionality
I had the same problem that the EnqueueAsync is not return on the latest version.
I had the same problem that the EnqueueAsync is not return on the latest version.
Ubuntu 22.04；Arm64 ；Docker
I had done this to fix it (.NET 6)
public static class IManagedMqttClientExtensions
{
public static async Task EnqueueAsyncWithTimeout(this IManagedMqttClient client, MqttApplicationMessage message, TimeSpan? timeSpan = null)
{
await client.EnqueueAsync(message).WaitAsync(new CancellationTokenSource(timeSpan ?? TimeSpan.FromSeconds(7)).Token).ConfigureAwait(false);
}
}
And then I call this extension method instead.
use the regular client instead
no， ManagedMqttClient works fine on windows server，but not on embedded devices. i use the regular client instead.
use the regular client instead
no， ManagedMqttClient works fine on windows server，but not on embedded devices. i use the regular client instead.
What I gave you didn't work?
@chkr1011 I did a bunch of changes to my code that uses the managedclient and I've started having freezes again. I thought it was the changes I did and I spent several hours debugging. Until I simply remembered this and downgraded back to MQTTnet.Extensions.ManagedClient 4.1.0.247 and everything started working again. Version 4.1.1.318 is totally unusable; you can only do a few publishes and then it freezes everything.
@iioter if you use the code I gave you above with MQTTnet.Extensions.ManagedClient version 4.1.0.247, it should be working.
public static class IManagedMqttClientExtensions { public static async Task EnqueueAsyncWithTimeout(this IManagedMqttClient client, MqttApplicationMessage message, TimeSpan? timeSpan = null) { await client.EnqueueAsync(message).WaitAsync(new CancellationTokenSource(timeSpan ?? TimeSpan.FromSeconds(7)).Token).ConfigureAwait(false); } }
Sadly that did not help. It is still not returning from the EnqueueAsyncWithTimeout and the message is not published. Only after i stop and start the mqtt server (mosquitto) the method returns
It looks like the problem is on "weak" computers. I have it also on an i5 computer with viewer resources.
Sadly that did not help. It is still not returning from the EnqueueAsyncWithTimeout and the message is not published. Only after i stop and start the mqtt server (mosquitto) the method returns
It looks like the problem is on "weak" computers. I have it also on an i5 computer with viewer resources.
Try it with MQTTnet.Extensions.ManagedClient version 4.1.0.247
Sadly that did not help. It is still not returning from the EnqueueAsyncWithTimeout and the message is not published. Only after i stop and start the mqtt server (mosquitto) the method returns It looks like the problem is on "weak" computers. I have it also on an i5 computer with viewer resources.
Try it with MQTTnet.Extensions.ManagedClient version 4.1.0.247
i did try it with MQTTnet.Extensions.ManagedClient version 4.1.0.247, it did not change anything
Also with the main library on that version?
On Thu, 20 Oct 2022, 06:06 nanuit, @.***> wrote:
Sadly that did not help. It is still not returning from the EnqueueAsyncWithTimeout and the message is not published. Only after i stop and start the mqtt server (mosquitto) the method returns It looks like the problem is on "weak" computers. I have it also on an i5 computer with viewer resources.
Try it with MQTTnet.Extensions.ManagedClient version 4.1.0.247
i did try it with MQTTnet.Extensions.ManagedClient version 4.1.0.247, it did not change anything
— Reply to this email directly, view it on GitHub https://github.com/dotnet/MQTTnet/issues/1424#issuecomment-1284893964, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF7U7YH6HDBTP36LFUQDT4LWEDAM5ANCNFSM5YNZZGYA . You are receiving this because you authored the thread.Message ID: @.***>
Also with the main library on that version? … On Thu, 20 Oct 2022, 06:06 nanuit, @.> wrote: Sadly that did not help. It is still not returning from the EnqueueAsyncWithTimeout and the message is not published. Only after i stop and start the mqtt server (mosquitto) the method returns It looks like the problem is on "weak" computers. I have it also on an i5 computer with viewer resources. Try it with MQTTnet.Extensions.ManagedClient version 4.1.0.247 i did try it with MQTTnet.Extensions.ManagedClient version 4.1.0.247, it did not change anything — Reply to this email directly, view it on GitHub <#1424 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF7U7YH6HDBTP36LFUQDT4LWEDAM5ANCNFSM5YNZZGYA . You are receiving this because you authored the thread.Message ID: @.>
Yes
@chkr1011 I did a bunch of changes to my code that uses the managedclient and I've started having freezes again. I thought it was the changes I did and I spent several hours debugging. Until I simply remembered this and downgraded back to MQTTnet.Extensions.ManagedClient 4.1.0.247 and everything started working again. Version 4.1.1.318 is totally unusable; you can only do a few publishes and then it freezes everything.
Description of my today's work. All problems with ManagedClient (constant freezes of EnqueueAsync()) disappeared after downgrading to 4.1.0.247.
A fix will be released soon. I will let you know as soon as a test build is available.
Please try version 4.1.2.350 from the myget feed and let me know if the issue is fixed.
Please try version 4.1.2.350 from the myget feed and let me know if the issue is fixed.
Anyone tried it yet? I don't wish to test in production.
Please try version 4.1.2.350 from the myget feed and let me know if the issue is fixed.
Anyone tried it yet? I don't wish to test in production.
I run it continuously for 3 days and everything works fine
With the extension method I provided or does it even work without it?
On Fri, 28 Oct 2022, 17:00 Sam, @.***> wrote:
Please try version 4.1.2.350 from the myget feed and let me know if the issue is fixed.
Anyone tried it yet? I don't wish to test in production.
I run it continuously for 3 days and everything works fine
— Reply to this email directly, view it on GitHub https://github.com/dotnet/MQTTnet/issues/1424#issuecomment-1295106334, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF7U7YCZQ2RZBEPXIX5UFZTWFPTBRANCNFSM5YNZZGYA . You are receiving this because you authored the thread.Message ID: @.***>
Cool, I will give it a try tomorrow.
On Fri, 28 Oct 2022, 23:00 Sam, @.***> wrote:
Without ur extension method.
— Reply to this email directly, view it on GitHub https://github.com/dotnet/MQTTnet/issues/1424#issuecomment-1295462104, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF7U7YDHT4A3CDRS5YCMYJDWFQ5HTANCNFSM5YNZZGYA . You are receiving this because you authored the thread.Message ID: @.***>
I try version 4.1.2.350 and my client stops to send messages after 10-30 seconds... EnqueueAsync method call never ends. version 4.1.0.247 works normally...
So if the issue is fixed and not fixed at the same time I assume there is another issue.