I am glad we have at least a workaround. You are right that the asynchronous operations are more scalable. At the same time, any single async operation is much more complex to perform, and thus there are many more chances for it to be buggy somewhere - that's why I have suggested this workaround. Without employing further tools (such as the OPC Analyzer) it is difficult to say on which side the problem is or what is its nature.

Whether or not the sync approach poses a scalability problems depends on how the whole system is set up. For example, if you are the only (or the main) OPC client to the server, and you are simply calling our EasyDAClient.ReadXXXX methods on a single non-isolated instance of the component, there won't be any harm doing OPC sync. Async will start showing its advantages (possibly) when there are more OPC clients (depends on the OPC server implementation, though), or when you are hitting the server by multiple operations from parallel threads in the same clients.

The total "hangs" may be in relation to RPC, yes, but it would be unusual - normally it's either the server or the client.

Setting the desired read/write method to asynchronous does not harm. But it truly has an effect only when both sync and async are enabled: in such case, it dictates the preference (for example, in the default setting both are enabled, and the desired is async, so normally async is chose, but if we detect that async is not available for whatever reason form the server, then still the sync can be chosen, because it's also enabled).

When only one from sync/async is enabled, then that one is always chosen.

Thank you for update. I will await the outcome of the steps suggested.

Best regards

I cannot find a consistent explanation. There always is something in the symptoms that contradicts the theory. Yes, my last post was leaning towards a "block" in the server, but that's when the timeouts should kick in anyway. That doesn't seem to be the case, but at the same time, the fact that terminating the server process "unblocks" things, indicates that a method call into the server might be blocked.

My previous questions were based on a different theory, and I will now return it. The fact that the Kepware server cannot be shut down may be due to a call blocked in a reverse direction: A callback from the server to the client component may be blocked inside the component (that should, of course, not happen if all works well). So I was about to propose to try something and see if it works as a workaround: Get rid of the callbacks. They basically happen for two reasons: subscriptions, and asynchronous operations. By default, even if you do not explicitly subscribe, EasyDAClient creates internal subscriptions. So we must turn that off. And, again by default, the Reads and Writes are performed using asynchronous variants of these OPC methods. So we must turn that off as well.

Can you please try this:

1. Run the EasyOPCOptions utility.
2. On the "OPC-DA Defaults" tab, under "Client Mode" group, uncheck "Allowed read/write methods: Asynchronous", (and only leave "Synchronous").
3. On the same tab, under "Update Rates", uncheck the box next to "Automatic - after read", so that the edit box turns to read "infinite".
4. Restart the component's process/service after the changes.

Thank you, and best regards

If things work as designed in QuickOPC, the ReadItem call should always return. If the data is not available in time (such as server bug - hang in the sync Read, or completion notification not arriving for async Read), it should still return, after a configurable timeout. This timeout, in the current versions, defaults to 1 minute, but can be changed.

Are you sure that you have seen a blocking that is significantly longer than that? If there is e.g. a Web server request processing timeout and is shorter, then the request processing might be terminated before we get a chance to return.

With your recent findings, something like this becomes more likely. If terminating the server leads to "unblocking", it means that we were waiting for something to complete in the server.