How to properly disconnect a Thingworx client programatically

[jnair1]

Hello,

I was trying to disconnect and reconnect to Server from Java SDK programatically. I have tried the method client.shutdown() but it's throwing an Exception and still tries to reconnect to the server. The method client.disconnect() also does not work, it may disconnect but its again reconnects to the server.

Anybody has an Idea how to reconnect a thingworx connection properly?

Thanks & Regards,

Jishnu Nair

[supandey]

Hi Jishnu, can you share you code snippet performing the connection and disconnection along with the exceptions from the console.

Edit:

shutdown() method should be enough to close the connection along with cleaning up of the resources of the client.

[supandey]

Just for the reference here's the sample structure :

try {

          // Create the client

          // Start the client. The client will connect to the server and

          // authenticate, using the Application Key specified above.

          client.start();

          // Wait for the client to connect.

               if (client.waitForConnection(30000)) {

               LOG.info("The client is now connected.");

          // Add activities here

     }

     else {

          LOG.warn("warning");

          }

          client.shutdown();

     }

          catch (Exception e) {

          LOG.error("error occurred during initialization", e);

     }

          LOG.info("Action completed. Exiting");

     }

Hope this helps. For more detail concerning the Java SDK please refer to the ThingWorx Java SDK Developer's Guide

[supandey]

Thanks for the sharing the exceptions, just so i understand the use case - is there a specific requirement to retry with different authentication if the first one fails?

Since, normally you would only use one account to authenticate the remaining tasks and their corresponding access rights would better be handled within using the Organizations/Groups/Users within the platform itself. I can try and have look at the code structure if you can share that as well.

Sushant

[jnair1]

Hello Sushant,

Yes, there is a concrete use case. If the client fails to connect using one URL& Appkey, it should connect to another URL.

Here is an example code I am trying to implement:

ClientConfigurator config = new ClientConfigurator();

config.setUri("url1");

config.setAppKey(appkey1);

client.start();

if (thingClient.waitForConnection(3000)) {

//Do something

} else {

client.shutdown()

config.setUri("url2");

config.setAppKey(appkey2);

client.start();

}

The code does work. But the client.shutdown() method fails to cleanly end the first connection and it is running in the background.

[supandey]

Thanks Jishnu for sharing all the additional information. I think the exception you are getting is from the failure of 1st URL configuration i.e. probably that URL is not reachable and thus you have the exception. Is this url1 reachable? I mean have you been able to make successful connection to url1 ?

As to the question of shutdown() it does kick in to perform it the resource clean, besides that's the only method i see which you can call to clean up the resources. May be someone else viewing this thread have different thought on this. Might i ask why you feel the resources are not properly cleaned by calling the shutdown() ?

[thearonh · Accepted solution]

Hello,

The error you are seeing is actually a bug that is being worked on internally and should be fixed with the 7.2 release.  The problem is that the Client-EndpointMonitor Thread you are seeing doesn't get properly shut down during certain shutdown cases, so it is trying to reconnect. However, the Exception happens because the server knows that the Channel has been closed, even though the Monitor is trying to connect on it.  The mess of errors are only internal to the client though, and do not mean that the connection is not up with your new config, it just means the monitor for the previous connection is also still running.

So, Sushant's original answer is the correct one - the shutdown() method should be all that you need to correctly shut down a thingworx client. Unfortunately this bug still makes it appear as though it hasn't been shut down correctly. 

[jnair1]

Thearon Helgeson​ : Thank you for clearing that up..