timtay-microsoft
commented
10 months ago Good catch. #1760 should fix this for you
Closed gabrielandrade2 closed 10 months ago
timtay-microsoft
commented
10 months ago Good catch. #1760 should fix this for you
gabrielandrade2
commented
10 months ago @timtay-microsoft , Thank you very much!
timtay-microsoft
commented
10 months ago Version 2.4.0 fixes this issue, so I'll close this thread
Context
Description of the issue
I was reworking my device's code to remove an older reconnection method that we used in favor of the SDK's internal reconnection mechanism. To test everything out, I set up an environment where I can block the device's connection to the internet in order to test the reconnection mechanism.
I am currently using the default
ExponentialBackoffWithJitterretry policy (however, I've already tested some variations of the parameters) and opening my connection usingDeviceClient.open(true);.(As context information, my device was a UI where the user have access to a toggle switch to enable or disable the IoT connection as he pleases)
While executing a test where I start the code already without internet access and attempt to open the connection, I noticed that the code is blocked in the
open()call (probably because of thewhile(true)loop inIotHubTransportclass). That is fine as I use a separate thread to open the connection.However, I realized that if the user toggles the switch to close the connection while the connection hasn't been established,
DeviceClient.close()also locks until either the retry policy expires or the OperationTimeout is reached. This appears to happen becauseopen()andclose()share the samestateLockinDeviceIOclass.This is a problem for me because, not only when the client attempts to close the connection it will be stuck, but it also delays the shutdown/restart of the IoT service within my device, as it attempts to close immediately all open connections/threads before finalizing itself.
I am not sure if this is an intended behavior on the SDK's part or, in fact, an actual bug. Still, I find weird not having an option to forcibly stop the connection attempt procedure and finalize all operations.
I would like to either have such an option for the SDK side or to know the proper way to handle this situation, if there is one. Currently, I was able to get around this issue by setting
client.setOperationTimeout(TimeUnit.SECONDS.toMillis(1));and then canceling the running task from my scheduler.Thank you for your support.
Code sample exhibiting the issue
I've written a sample code that demonstrates the situation. I've used an operation timeout of 60 seconds and a delay before attempting to close the connections of 10 seconds, for sake of speed, but those values can be changed, and the behavior should be the same. In fact, I work with larger values in my actual device.
The code should be run without internet access to reproduce the same results.
Console log of the issue
In the attached console output, it can be seen that the
Device.close()call starts at01:41:56,231, but effectively executes at01:42:46,468, exactly 1 minute after the connection attempt and when the operation timeout is reached.