Should I set a timeout at all when using get() on the returned future from client's connect() method ?

[FSangouard]

Hi,

I'm on v0.6.8 and sometimes, after multiple connections/deconnections to a server, I see leftover TCP connections from my client to the server, although disconnect() was called as many times as connect(). I suspected some kind of race condition in case of timeout during connect(), so I set up a repro case on my machine with a very small connection timeout to trigger the problem reliably. I observed the same thing and upgrading to 0.6.15 didn't change anything.

However, I realized that the timeout exception I was getting was coming from the get() on the future returned by connect(), not from the connect() itself. Up until then, I was using the same timeout value for the get() as was configured inside the OpcUaClient as the connectTimeout. I tried using a bigger value for the get() timeout, and I started seeing exceptions coming from the connect() method itself (with a Bad_Timeout OPCUA status code) and I also got less leftover TCP connections after the test, even none at all with a sufficiently big timeout on the get().

So going back to my question, is it best to just use get() without a timeout since it won't block indefinitely if the connection actually times out anyway ? Is there any case where it would block indefinitely and setting a timeout would help ?

I can't really use a purely async model in my case (or maybe it's possible but I can't do it).

I can share the repro case if needed.

[kevinherron]

The CompletableFuture returned by connect() should never block indefinitely.

But once you call connect() you do need to make sure to call disconnect() at some point or the state machine will keep trying to make you connected.

[FSangouard]

OK, thank you for your quick reply!

I think those leftover TCP connections were due to a couple of mistakes in my implementation:

• setting a timeout on the get() identical to the connectTimeout of the client, which created a race condition where a timeout would sometimes be triggered although the connection was actually established. When this happened in my reconnection loop, it forced it to continue trying since it considered that iteration to have failed, causing extra calls to connect() => just don't set a timeout on get()
• clobbering the OPCUA client with a new instance in each iteration of my reconnection loop, which in combination with the previous point caused new connections to be created and later down the line prevented the call to disconnect() from closing those connections => reuse the same client instance

Sorry for bothering you with this, and great job on this project by the way!

[kevinherron]

Thanks!