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

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

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

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

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

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