I am trying to provide a UI to allow users to configure and connect to ThingWorx via a component that uses the .NET Edge SDK. However, I have encountered a number of issues with the .NET Edge SDK (version 126.96.36.1999), and some seem to suggest there is static state in the API.
I attached a test application which is based on the SteamSensor sample included with the SDK. In order to let the user change the ThingWorx connection settings, and reconnect, I am creating a new instance of a SteamSensorClient with the new configuration whenever they 'Connect'. However, some static state in the SDK seems to affect behavior across these instances.
- Using disconnect(string reason) method, new instances of SteamSensorClient can connect with a bad URI (probably application key as well) - Start the test application, enter good settings, and Connect. Then Disconnect (not Shutdown), change the URI to be incorrect, and click Connect. The brand new SteamSensorClient seems to be able to connect even though the incorrect URI is passed into the constructor. This does not seem to be the case when using the shutdown() method instead (try Shutdown from the test application).
- Connecting to the incorrect URI seems to put the SDK into a bad state, and recovery is a problem - Start the test application, enter a URI with a slight mistake (still correct format, but not pointed to the real endpoint), and Connect. For me, this takes > 1 min before failing. Now correct the URI, and try to connect. This does not seem to work even though it's a new instance of SteamSensorClient with the good URI. Open another instance of the test application, and enter the same good settings in, and connect. This should work, verifying that the settings themselves are good. Unlike #1, this problem seems to apply with shutdown() as well as disconnect().
- On a slight tangent, the ConnectRetries and ConnectTimeout settings do not seem to be consistent with the actual behavior when Connecting. The code documentation indicates ConnectTimeout should be in milliseconds, but in practice I am seeing much longer times to fail. Also a ConnectRetries value of 0 seems to mean it won't connect (perhaps it is actually 'Tries' and not 'Retries'?)
- Is there a way to abort the connection request? The test application permits calling of disconnect() and shutdown() during the connecting state. Start the test app, enter incorrect URI, connect. While it is in the 'Connecting' state (thread is blocked in the start() method), press Disconnect/Shutdown. The methods return, but do not abort the connecting state. Is there a way to do this?
- Should I be using one instance of SteamSensorClient and changing the settings instead somehow? Or is my use case not supported at all, and the process loading the SDK isn't expected to change settings and try to connect again?
Regarding #4, I found the BaseClient.stopConnectionAttempt(), but after trying it, it does not seem to actually stops the connection attempt. It returns, but the start() call remains blocked.
Regarding #2 & #3, I am finding that a bad hostname seems to fail relatively fast, and does not put the API into a bad state. However, other issues in the URI like the port or the path will take > 1min to fail and causes the problem I described. Also, I am finding that the protocol portion of the URI seems to be ignored; I can connect using 'foo://localhost:8443/Thingworx/WS'.
Further look into #3, it seems that the 'ReconnectInterval' setting (default 60) is probably the cause of the ~1 min to fail.
Message was edited by: Ting Zuge
Example.zip 2.4 MB