Professional OPC
Development Tools

logos

Publishing has halted on the client session

More
03 Jul 2019 19:28 #7487 by support
Hello.

Ad A: I do not know whether StatusSubscriptionSamplingInterval has effect. It may have. The status subscriptions cause some load on client/connection/server. Normally this is not an issue. It would be worth trying to turn them off completely: set EnableStatusSubscription property (on the same object) to 'false'.

Ad B, C: I understand the reason for using Isolated - that's the only way to get the event notifications the way you want then.Unfortunately, that (more precisely, the fact oof having separate EasyUAClietn instances) also adds some resource consumption (in this case, on the client side only).

As the issue appears to have at least some relation to threading, please test with setting the QueueCallback on each EasyUAClient to 'false'. In the default ('true') state, there is (basically) an extra thread/task on each EasyUAClient that delivers the event notification or callback to you, from an intyermediate queue. Turning it off should result in less resource consumption. It is, however, somewhat dangerous in the sense that your event processing will now have much easier chance of spoiling something inside the component - that will happen if the event processing either takes long, or when you happen to call back (directly or indirectly - sometimes it happens in surprising ways) into the component inside , which could cause deadlock.

I assume there are no Internal Errors in the LogEntry events - is that correct?

The memory consumption is also suspicious, although it may not be related. Is there a chance to attach a memory profiling tool and figure out which objects are responsible for the most of it?
Is your app running in a 32-bir or 64-bit process?

Regards

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

More
02 Jul 2019 14:23 #7473 by sjscheider
Thanks for the information.

A. Does StatusSubscriptionSamplingInterval have any effect on the issues we are having?

B. Yes we are setting the isolation to true based on your recommendation. When it was set to false we were getting connection status messages multiple times for a single device. So if we have 100 devices and 1 disconnected, we'd get 100 disconnecting events and then 100 disconnected events. Setting isolated to true resolved this issue. You indicated that this reason was too complex to explain.

C. We have a single EasyUAClient for each device. I have attempted to rework the code to use a single EasyUAClient and I was creating more issues than I was expected so I abandoned that effort. I was hoping it was going to be easier. Unless you are sure that this would solve all of our issues, I'm hesitant to go down that path again.

D. OK

One other issue we are encountering that may or may not be related. We notice that our app uses way more memory when there are disconnected devices. Yesterday the app was consuming more than 2 GB of memory when about 25 out of 125 where disconnected. When we reconnected the devices, the memory when back down to about 500 MB.

Thanks,
Scott

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

More
02 Jul 2019 06:58 #7472 by support
Thank you.

A. Setting ServerShutdownRetrialDelay is irrelevant to the issue. It only applies when the server itself specifically informs the client that is being shut down, which is not the case here.

B. I noticed you are setting Isolate = true on the EasyUAClient. Was there a reason for that?

C. Do you use a separate instance of EasyUAClient (with Isolated = true) for each of your device connections or just one for all of them?

D. Given that splitting the app into 2 instances resolves the issue, I definitely agree with your assessment of the issue - it is not a lack of some system-wide resources; it it is probably some resource limitation that is per-process. At this moment I do not know what that is.

Kind regards

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

More
01 Jul 2019 20:07 #7468 by sjscheider
Just providing an update on this issue. We are still experiencing the issue with subscription timing out.
ErrorMessageBrief: The OPC-UA subscription ID 174 publishing has halted on the client session to endpoint URL "opc.tcp://10.0.9.3:4840" for approximate current duration of 16533 milliseconds. The current keep-alive count is 10, the current publishing interval is 1000 milliseconds, and the probationary period was 5000 milliseconds.
When we subscribed to the most common event of our three events at 2000 ms, we could handle about 230 devices. We double the subscription time and we were able to handle about 260 devices. When we went to 5000 ms, we were about to subscribe to about 290 devices.

So we have started running 2 instances of our software on the computer, each connected to a max of 150 devices, so 300 in total, without issues. So the limitation is not the hardware or environment, it seems to be within our code or the OPC Labs code. Do you have any suggestions? In a previous thread you had indicated that 500 to 1000 connections would be expected.

One change that we did make was to increase the threads with .NET Core.
ThreadPool.SetMinThreads(1000, 100);
The default worker thread default is very low, I think is was 8 or 12 on our test systems. (It is based on the number of cores I believe.) As we increased this number, the number of devices we could connect to increased. Once we increased is based 500, we so no more improvement. The number of devices above was achieved with the thread count set to 1000. When the subscription issue occurs, the number of thread increases to over 1000.

We also changed with setting but didn't really notice an difference with performance.
EasyUAClient easyUaClient = new EasyUAClient { Isolated = true };
easyUaClient.IsolatedParameters.SessionParameters.ServerShutdownRetrialDelay = 30000; // default is 10000
easyUaClient.IsolatedParameters.SessionParameters.StatusSubscriptionSamplingInterval = 45000; // default is 15000
Again, any recommendation you might have would be appreciated.

Thanks,
Scott

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

More
02 Jun 2019 12:24 - 02 Jun 2019 12:25 #7431 by support
I am still on travel but was able to have a look at the XML config issue. I have found that under .NET Core, XML config custom section probably work, but the diagnostic switches settings and the trace listener settings do not (although the Microsoft official documentation says that do). Unfortunately, we need all these elements to work in concert. We will need to provide some configuration method for .NET Core in the future version, I have made a note, but currently it's just not possible.

What to do now?

First option: Try to run the same code under .NET Framework. If it would manifest the same problem, enable the extended tracing, and we will analyze the data. There is a high similarity between the two codebases, so the analysis result will most likely still apply to .NET Core.

Second option - if the first one fails: Attempt to do the analysis without extended tracing, using Wireshark trace, and additional pieces of information such as EasyUAClient.LogEntry notifications.

Either way, it is crucial to use a "minimal" scenario where it happens (as few devices as possible etc.). The amount of data may be huge, and the analysis is a painful process nevertheless, so minimizing the scenario is a paramount for success.

More information: kb.opclabs.com/Collecting_information_for_troubleshooting

Best regards
Last edit: 02 Jun 2019 12:25 by support.

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

More
31 May 2019 01:30 #7429 by support
Hello.

I have tried that now quickly with .NET Core console app, and could not get it to work either.
I need to ask you for patience. I will have further look at this, but I can only do so when I return from my travels, which will be at the end of next week.

Best regards

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

More
30 May 2019 15:34 #7424 by sjscheider
It is a .Net Core console app.

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

More
30 May 2019 14:20 #7422 by support
No, there isn't any other way, at least not in the current version. I wasn't aware that there is an issue with XML config file in .NET Core (if there is an issue). What kind of .NET Core project are we talking about? Console app? Or ASP.NET? Or something else?

Best regards

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

More
29 May 2019 15:32 #7419 by sjscheider
I can't figure out how to get the XML config working in a .NET core app. I don't want to say it doesn't work at all, but I can't seem to find any example of it online.

Is there another way of setting these values? Can it be done directly in code.

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

More
29 May 2019 02:35 #7417 by support
Hello,

are you saying that the method with XML-format .config does not work for you in .NET Core? Or is it that you would just prefer to use JSON settings?

I am now on travelling and it is a bit difficult for me to actually verify how that behaves in .NET Core. But from what I know, the XML format should still work.

Best regards

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

Moderators: support
Time to create page: 0.207 seconds

      

 Recommend this on Google