Fix runaway thread issue where MqttClient uses 100% CPU when disconnected #75
Conversation
…ailed connections Signed-off-by: Marcus Hellsten <[email protected]>
Signed-off-by: Marcus Hellsten <[email protected]>
… email with accepted ECA. Signed-off-by: Marcus Hellsten <[email protected]>
|
I don't know why the Eclipse validation is not passing. I have signed the ECA, the author of the commits is the same as the email I signed with, and I added sign-offs with that same author email. |
|
If you just signed the ECA, give it a day or two. It seems that there is a bit of a delay in the ECA's getting back to GitHub. |
…cer in front of them, the connection may be accepted even though nobody is listening. In that situation, when reconnecting, we may end up waiting indefinitely for the KeepAlive thread to exit, when in fact it already stopped as part of the original disconnection event.
|
Is there any update on when this PR might be completed? |
|
FWIW, I've been running my forked version in production since January without issue. I also ported it to .NET Core. Since other PRs for .NET Core have been ignored, I gave up on running a mainline version. Because I'm unable to find SDKs for some of the old platform targets in the solution, I had no way of building the whole thing, and therefore didn't push those changes to my public fork. |
|
@mhellsten Good to know, thanks for the update |
|
I have encountered this problem as well, but with a twist: if you attempt to connect with the wrong user name or password, the connection is rejected, but three receive worker threads are started anyway and spin, hogging the CPU. Do we have any idea when this fix will be merged and published through NuGet? I see this problem with both versions 3.6 and 4.3. |
I wouldn’t hold my breath since the project hasn’t been maintained in three years. You could use my fork to build the package yourself. |
|
I may just do that. Though it really would be nice to see the NuGet stuff updated too.
…--Rick
From: Marcus Hellsten ***@***.***>
Sent: Wednesday, January 19, 2022 6:34 PM
To: eclipse/paho.mqtt.m2mqtt ***@***.***>
Cc: Rick Papo ***@***.***>; Comment ***@***.***>
Subject: Re: [eclipse/paho.mqtt.m2mqtt] Fix runaway thread issue where MqttClient uses 100% CPU when disconnected (#75)
Do we have any idea when this fix will be merged and published through NuGet?
I wouldn’t hold my breath since the project hasn’t been maintained in three years. You could use my fork to build the package yourself.
—
Reply to this email directly, view it on GitHub <#75 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANOHQTLGIYEJ3LRTODZPD2TUW5DAHANCNFSM4EIQCYJQ> .
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .
You are receiving this because you commented. <https://github.com/notifications/beacon/ANOHQTJMSVBNEJ754HF64OTUW5DAHA5CNFSM4EIQCYJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHSO3JJY.gif> Message ID: ***@***.*** ***@***.***> >
|
During contention conditions, the broker (for example RabbitMQ) might disconnect the client before it is fully initialized. This might put MqttClient's ReceiveThread thread into a tight loop that it never recovers from, running the client machine out of CPU resources.