Hello @tsun,

You should be able to reconnect when it's broken, just not repeatedly and unlimited number of times. When the connection is up, you should be able to issue requests. To test this capability, you can use the subscription test example from SDK, modifying it like so (just for the capability test):

    for(int i = 0; i < 10; i++) { //tight loop 
    	DacsSubscribeClient client = null;
    	try {
      		client = new DacsSubscribeClient(daemonHost, serviceName, name, position, application, usage,  reqtype);
		client.openDaemonConnection("DACS", "dacsSubscribeClient", true);
		 client.login();
      		// Wait for processing event queue dispatching.
      		client.waitForCallBackEvent(waitTime);
 		client.checkSubscribePermission(itemName, peList, enableOndemand);
 		// Again, wait for processing event queue dispatching.
		client.waitForCallBackEvent(waitTime);
      		client.logout();
	}  catch (Exception ex) {
   		// Other unexpected exception occurs.
      		System.err.print("DacsSubscribeClient failed ");
        	if (ex.getMessage() != null && ex.getMessage().trim().length() != 0) {
       		System.err.print(ex.getMessage());      	}
      System.out.println();
    	}  finally {
      		if (client != null) {
        	client.closeDaemonConnection(true);
      	}
    }

The result you should get is that you will be able to reconnect when DACS is ready, not in a tight loop, similar to mine:

Output:
[host:port] Daemon connection state is UP
[] Daemon connection opened
[] radmin logged in
[] Subscriber has been logged in
[] radmin allowed subscription access to item IBM.N
[] radmin logged out
[] Daemon connection closed
[] Daemon connection state is DOWN
[] Daemon connection closed
[] Daemon connection state is UP
[] Daemon connection opened
[] radmin logged in
[] Subscriber has been logged in
[] radmin allowed subscription access to item IBM.N
[] radmin logged out
[] Daemon connection closed
[] Daemon connection state is DOWN
[] Daemon connection closed
[] Acquire AuthorizationSystem failed
[] Daemon connection state is DOWN
[] Daemon connection closed
[] Daemon connection state is DOWN
[] Daemon connection closed
[] Daemon connection state is DOWN
[] Daemon connection closed
[] Daemon connection state is UP
[] Daemon connection opened
[] radmin logged in
[] Subscriber has been logged in
[] radmin allowed subscription access to item IBM.N
[] radmin logged out
[] Daemon connection closed

Please note, we do not recommend reconnecting repeatedly without the need, this modification can be is for the development and test phase, the way to verify the reconnect working.

Hello @tsun,

You should be able to create connection to daemon, issue request, tear it down, then repeat. There can not be unlimited number of those connections, still there should be more then one permitted by DACs to complete before they start to fail.

I am just wondering, instead, can you issue the requests without creating and destroying the connection? That would be more efficient, I modified the Java subscribe example from the toolkit to make repeated checkSubscribePermission() calls:

client.login();
   for(int i = 0; i < 1000; i++) {
      // Wait for processing event queue dispatching.
      client.waitForCallBackEvent(waitTime);
      client.checkSubscribePermission(itemName, peList, enableOndemand);
      // Again, wait for processing event queue dispatching.
      client.waitForCallBackEvent(waitTime);
   }
      client.logout();

it resulted in positive responses

...
allowed subscription access to item IBM.N
allowed subscription access to item IBM.N
allowed subscription access to item IBM.N
...

Calls do not have to be the same, just simpler to create multiples this way.

Thanks. It's fine to keep the only connection open in our unit tests, but the real concerns is what happens if the connection is broken, and we cannot re-connect in the real time fashion for our production? Could you please finding out what we should expect in term of connection STATE check whenever we are in the need to re-connect? Seems to us CONNECTION_DOWN is always returned first during the re-creating.