Professional OPC
Development Tools


State that causes the ReadItem to block indefinitely

01 May 2014 12:05 #1914 by support
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.

Please Log in or Create an account to join the conversation.

30 Apr 2014 16:45 #1910 by dlbrown06

This appears to have resolved the issue. Running in Synchronous mode isn't causing the server_runtime.exe process to begin blocking.

Do you have any idea why using Async could be causing our issue? This application needs to be scalable and I'm concerned with having this defaulted to Sync.

Please Log in or Create an account to join the conversation.

24 Apr 2014 06:51 #1885 by support
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.

Please Log in or Create an account to join the conversation.

23 Apr 2014 20:57 #1880 by dlbrown06
I was able to put the changes you suggested in, so I'll let you know if anything further happens.

Just to note, I changed Desired read/write from Asynchronus to Synchronous. I assumed since I unchecked allowing async, I should changed the desired method as well.

I provided a process dump of the server_runtime.exe and at first glance they haven't noticed any issues yet. They believe the root of the issue may be in the RPC layer.

Please Log in or Create an account to join the conversation.

23 Apr 2014 11:48 #1879 by support
Thank you for update. I will await the outcome of the steps suggested.

Best regards

Please Log in or Create an account to join the conversation.

21 Apr 2014 21:24 #1877 by dlbrown06
I haven't yet tried your recommendation and I will try to do it sometime this week (getting access to their server can be difficult at times). However the server crashed again and I was able to track it down to when I ReadItem initially. It is able to create the COM objects and then just blocks on the Read call.

Like I mentioned before, I was able to recover by ending the server_runtime.exe process.

Please Log in or Create an account to join the conversation.

18 Apr 2014 12:24 #1867 by support
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

Please Log in or Create an account to join the conversation.

17 Apr 2014 19:26 #1863 by dlbrown06
Last time this issue occurred was this morning at 10AM EST and I watched the browser load for > 4 minutes. I changed all the timeouts to 10 seconds.

Next time this occurs, I'm going to try to step through it when it isn't working to try to find the exact line and call that is stopping further execution.

That is what I find interesting about this as well. Typically the web request should time out after 30 seconds of no response. However, this never seems to timeout.

I'm going to go into apache and double check the timeout that is set. So you think that you may be waiting for Kepware to respond with something? But shouldn't it timeout after 10 seconds if Kepware doesn't respond?


Please Log in or Create an account to join the conversation.

17 Apr 2014 19:14 #1862 by support
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.

Please Log in or Create an account to join the conversation.

17 Apr 2014 18:03 #1860 by dlbrown06
Are there cases that when I try to read or write the object would just block indefinitely or longer than a few minutes?

I have everything in try catches where the catch logs to the event log with an exception but I'm not getting any information back when this happens making it very difficult to diagnose.

Our customer is currently down now due to this issue and I need to track down where this is originating.

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.222 seconds


 Recommend this on Google