-
Notifications
You must be signed in to change notification settings - Fork 381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IoTHub client stuck in endless 'Unexpected disconnect' state #1173
Comments
"Unexpected disconnection" occurs when the connection between the client and the IoT Hub is lost. If you're seeing an uptick in the last week, it likely has more to do with your particular network environment and IoT Hub configuration than it does the SDK itself (2.12 was released over a year and a half ago, and has had no notable connectivity issues we know of at this time) You may want to try upgrading to the newly released SDK 2.13 just to be safe, but the fixes we added there likely won't change what you're experiencing. My first instinct would be to make sure that you aren't using any duplicate client IDs/connection strings, but it sounds like you've already checked and ruled that out as a possibility. Double check if you can - this is the most common reason connection failure like this happens. Assuming it's not that, we'll need to take a look at the logs to see if there's something deeper going on - you can enable logging in your application by adding the following lines:
That said, most likely this is an issue on the Hub/cloud side rather than the SDK, so there may not be much to see here. But if you can get us some logs, we'll take a look, and see if we can't at least get a hint of what's going on. |
Hi, we actually had to migrate to using the servicebus queue that we were having the messages routed to in order to hotfix this as it was causing some issue in production. It seems like using the service bus queue directly is way safer to avoid this kind of issue, do you think there might be and cons? On the logging side I tried to trace back some old logs but the only thing I found is I get "Cannot connect to IoT Hub", when I get this kind of bad connectivity I re-try a couple of times and then just fail the request, I suspect this might be due to a network issue. My line of thought is that we might get a bad network connectivity in the middle of having an open IoTHub connection, and when we try to disconnect from it if the network is still bad we fail to disconnect properly and that leaves us with a hanging connection and on the next loop when we open a new connection and the network connection is back to good this two connections start to clash, do you think this is a possible scenario in our case? |
It's hard to say without logs, but that could be the beginning of an explanation. The Hub should eventually kill the connection on its end, but there would be a delay before that happens. However, when you get a good connection and connect to the IoTHub again, that should allow the new connection to be established while booting the old connection (which was already dead), so I don't think it's a sufficient explanation (assuming you're connecting with the same client ID). |
Close due to inactivity |
Context
Description of the issue
When I try to open an IoTHub conenction and send a message to the IoTHub device to be routed to the correct servecicebus queue I sometimes get the following error(the log that says:
This actually ends up sending hundred of duplicates of the message to the servevicebus queue. The IotHub client is used to send messages every 1-2minutes and every time I send a message I follow this steps:
This issue seems to be happening really often now, about a week ago it was happening only from time to time, but in the last 6-7 days it happens very often, maybe more than a couple of times a day.
I've checked and I am sure there isn't any other device that connects with the same connection string and I shutdown each client before I try to create a new one and use it.
I've also tried checking the device twin to see if it is hanging on status 'Connected' when there were no IotHub instances created and it was not, the status in the device twin was 'Disconnected' which is correct
Is there any solution to this to make sure this never happens apart from migrating to using the servicebus queue directly instead of the IoTHub message routing functionality?
Code sample exhibiting the issue
Console log of the issue
The only log indicating the issue that start appearing all over the application logs:
The text was updated successfully, but these errors were encountered: