Professional OPC
Development Tools

logos

Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

Asynchronous read and write with the EasyUAClient example?

More
13 Dec 2014 09:17 #2571 by support
We have fixed the issue with >= 64 WaitHandle-s. It is in QuickOPC 5.32 build 505.1, which is now on our download page.

If you decide to upgrade to version 5.32 from any previous version, please pay attention to the "What's New" document, and particularly to the change where the runtime assemblies are no longer installed into GAC by default. For this reason, it is highly recommended that you *uninstall* any previous version first, instead of simply applying version 5.32 over the existing installation.

Best regards

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

More
10 Dec 2014 14:08 #2563 by support
Thank you. I was now also able to reproduce the problem with >= 64 WaitHandle-s as well. A fix should be available in a matter of days. It will go into the version 5.32 which we have released approx. a week ago.

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

More
09 Dec 2014 17:30 #2558 by rvbr@allseas.com
I am glad I was able to help... And thanks for keeping me in the loop!

I rewrote my (to be production) code using the "OpcLabs.EasyOpc.UA.Reactive" interface. This is a far better match, when using the OPCLabs UA client in combination with the TPL Dataflow framework and a lot of async/await stuff.

Will do some more testing with the reactive extensions approach tomorrow ;)

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

More
09 Dec 2014 10:10 #2556 by support
Thank you for the code. I confirm that I am able to see the problem - although, at the moment, not precisely the same as you reported (instead of the WaitHandles limitation, I get an AggregateException with NullReferenceException in it; but I did this first test with the Debug build which is a bit different).

Anyway, there is a work to be done. I will keep you informed about the progress.

Best regards

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

More
08 Dec 2014 10:38 #2551 by rvbr@allseas.com
I hacked a little example application together to reproduce the "The number of WaitHandles must be less than or equal to 64." on the OPC Labs sample server. The exception information is not extremely useful, this is why I created the code to reproduce the problem.

Basic steps to produce this problem:
- Run more than 64 parallel requests with the EasyUAClient with the Isolated value set to TRUE (in this case a Parallel.Foreach with 100 instances).
- The attached example does a read value before the subscription (but I don't think its needed to reproduce the problem).

After the "The number of WaitHandles must be less than or equal to 64." exception, the OPC Labs sample server is also broken, as it will no longer accept subscriptions. The sample server service needs to be restarted before is works again!

PS. Please keep in mind that this code is no production code, but just a quick test to reproduce the problem!
Attachments:

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

More
06 Dec 2014 09:08 #2546 by support
No, the EasyUAClient does not support asynchronous read and writes in this way.

For "A first chance exception of type 'Opc.Ua.ServiceResultException' occurred in Opc.Ua.Core.dll", the details are missing from your report - the actual service result that indicates the problem would help.

The "BadTooManySubscriptions" does not mean that the server is broken, it just means that you have reached its limitations. The OPC UA sample server comes from OPC Foundation.

I would be highly interested in seeing the call stack from the exception "The number of WaitHandles must be less than or equal to 64." - can you provide it if you see it again please? The reason for it as that we are well aware of the "64" limitation, and we have code to overcome this limitation - but it looks like you have encountered a situation where it can still happen.

Note: I assume that you are not debugging the problems using breakpoints - because, it is not possible. The principle of the OPC UA keep-alive mechanism cannot coexist with pausing the client program for extended periods of time. We are trying to make the situation a little better - there is a discussion about it in the documentation - but the conclusion still holds, breakpoints won't work well with keep-alive.

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

More
05 Dec 2014 12:51 #2542 by rvbr@allseas.com
Moving the small number of data writing client instances to there own isolated instance, while using a non-isolated client for the far larger number of subscriptions, seems to be the most stable and scalable setup for now.

I ditched the synchronous read that I did before a subscription. So now I have to wait until the first sensor update before all the data is initialized. This will not be practical for all data sources, but we will cross that bridge when we get there.

But the question still remains: Is it possible to do asynchronous read/write operations on the UA client (like on the .NET and DA client)? :dry:

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

More
05 Dec 2014 09:19 - 05 Dec 2014 09:23 #2540 by rvbr@allseas.com
Thanks for the info. But I have been messing around with the the parameters of the keep-alive and the reconnection speed, but these settings are very environment depended. So if this fixes my problems on my low ping, idling server on my development machine, it will for sure fail in an off-shore environment. (System needs to run on a (properly) busy server on a ship.)


The .Isolated makes the behavior even less predictable:
  1. The subscriptions will still get the: "The OPC-UA subscription publishing has stopped." exception.
  2. The synchronous read will produce a: "A first chance exception of type 'Opc.Ua.ServiceResultException' occurred in Opc.Ua.Core.dll" exception.

The subscriptions will also fail to recover from there "The OPC-UA subscription publishing has stopped." exception (or it takes way longer).

If you push the number off instances a bit further then a additional exception occurs:
"A first chance exception of type 'Opc.Ua.ServiceResultException' occurred in Opc.Ua.Core.dll
OPCStressTest.vshost.exe Warning: 0 : * Transformed from: An exception of type 'Opc.Ua.ServiceResultException' from source 'Opc.Ua.Core' has occurred in OPC-UA SDK action 'DiscoveryClient.GetEndpoints'. The exception descend follows.
(1) {Opc.Ua.ServiceResultException} Opc.Ua.Core(End) -> Error establishing a connection.
"

All these blocked tasks will eventually result in the final neck shot exception: "The number of WaitHandles must be less than or equal to 64.".


Side note: I was able to "break" the OPCLabs sample server, it returns the following exception for a subscription request (even from the EasyOPC-UA Demo Application):
"OPC-UA service result - BadTooManySubscriptions.
---- SERVICE RESULT ----
StatusCode: {BadTooManySubscriptions} = 0x80770000 (2155282432)
"


While exploring all these possible ways of breaking stuff can be fun and useful, I like to go back to my original question.

Is it possible to do asynchronous read/write operations on the UA client (like on the .NET and DA client)?
Last edit: 05 Dec 2014 09:23 by rvbr@allseas.com.

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

More
04 Dec 2014 20:26 #2535 by support
The exception "The OPC-UA subscription publishing has stopped." is caused by a failure coming from the OPC UA keep-alive mechanism. Since the reads and writes use the same UA session as the subscription, it is possible that a blocking read or write will (properly) cause the keep-alive failure. I cannot if this is truly the case, but it can be.

If so, I can think of two possible remedies:

1. Tweak the parameters of the keep-alive. I think we have some public parameters available for this. Let me know if you are interested in following this route, and I will try to look up more info.

2. Use one session for the subscriptions, and a separate session (or sessions) for blocking reads and writes. This can be enforced by the mechanism I mentioned in the earlier post, i.e. setting the .Isolated flag on the EasyUAClient as needed.

Best regards

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

More
04 Dec 2014 17:14 #2533 by rvbr@allseas.com
First I have to say that after some more testing, it seems more probable that KEPServerEX 5 is blocking the connection to the client, and that its not the EasyUAClient itself that is causing the the "timeout" issues.

I can set up +100 parallel tasks that subscribing to the OPCLabs sample server, but when I do the same to the KEPServerEX 5 it gets really slow. Especially when I perform a read before adding the subscription.

When the subscription is running and I start additional reads (by adding tasks or separate program) then the running subscriptions will return the following exception: "The OPC-UA subscription publishing has stopped."

When I stop the separate program the connections will recover after a while.

So it seems that the synchronous read and write actions are blocking the connection to KEPServerEX :(

Its also possible to let the synchronous read fail, but I can't reproduce the issue currently.

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

Moderators: support
Time to create page: 0.061 seconds