After some investigation, this behavior appears to be by design. You have hit upon a special case that only happens when several conditions are fulfilled together:

1. The last EasyDAClient is being disposed, and
2. There are some open connections to OPC-DA servers, and
3. It takes the OPC server time to fulfill the disconnect.

We cannot leave any OPC server connected when all EasyDAClient-s are disposed: It would not allow a proper tear-down of the process with regard to the connections, plus we would be accused of leaking memory (the memory associated with the connections). And, in this particular case, we cannot do this "in background", postpone it possibly after the Dispose() returns, for the same reasons as just explained. If it so happens that the OPC server does not disconnect quickly, we have to wait. When the OPC Kit Server encounters the last release (which is when it has been connected from just one client and this client is disconnecting), it takes some time (approx. those 3 seconds) to perform the disconnect. I have not investigated into detail what happens and why inside the server, but it is not relevant for the client side anyway.

If you do not want this behavior, you can work around it. For example, in the code you have sent, if you create one additional EasyDAClient() at the beginning of Main(), and then Dispose() it at the end, it will only be this additional last Dispose that will take some time. And sometimes, in reality, not even that, because if, for example, enough time passes and QuickOPC disconnects from the server because of inactivity, the last Dispose() will not have to do it, and will be therefore fast as well.

I used QuickOPC 5.31 and I confirm that I was able to reproduce the 3-4 seconds EasyDAClient.Dispose() times as well.

What is truly weird is that, as you have discovered, the opcrtkit.exe process must not be running for this to happen. When it is running, the times are around 1 second.

I will investigate this.

From: B.
Sent: Thursday, August 28, 2014 3:42 PM
To: Zbynek Zahradnik
Subject: "Long call time" to execute EasyDAClient.Dispose()

Zbynek,

S. have encountered a behavior with EasyDAClient.Dispose method we cannot understand.

[...] we have three channels in the [...] OPC-server we sample each 30 seconds.
Each channel is sampled in this way:
• Create a new thread to sample the channel.
• The thread has an own instance of the EasyDAClient class.
• Reading the tags for the channel.
• When the channel is sampled I call the EasyDAClient.Dispose method.
When this is done we do the same for the second channel and at last the third channel.
After the third channel is sampled, the EasyDAClient.Dispopse method always take about 3-5 seconds to execute. The two earlier calls take only a few milliseconds.

S. would like your opinion on this. Is this an issue or something we should just ignore.

S. have managed to reproduce the behavior “somewhat”. In the picture below he has print the times before and after he call of the EasyDAClient. Dispose method. Notice the time between is about 4 seconds. Hope this is a way to reproduce it.



You can run my test for yourself, please see attached code. I use QuickOPC V5.23.1052.1 for this test. Make sure your OPC-server IS NOT running when you start this.

/S.

Today we got an report from a customer and S. made a TeamViewer connection. Sometimes dispose can take there more than one minute before it’s ready???

Something is wrong here. In the future we will have the possibility to have a sample rate on one second or shorter. To have a dispose which take so long time make this impossible. As S. say in version 3 of QuickOPC we didn’t need to use dispose but in version 5 we have to [...].

What do you think about all this?

Best regards
/B.