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.
- Forum
- Discussions
- QuickOPC-UA in .NET
- Reading, Writing, Subscriptions
- Publishing has halted on the client session
Publishing has halted on the client session
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.
- sjscheider
- Topic Author
- Offline
- Platinum Member
- Posts: 40
- Thank you received: 2
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.
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.
- sjscheider
- Topic Author
- Offline
- Platinum Member
- Posts: 40
- Thank you received: 2
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.
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);
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
Thanks,
Scott
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
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.
- sjscheider
- Topic Author
- Offline
- Platinum Member
- Posts: 40
- Thank you received: 2
Please Log in or Create an account to join the conversation.
Best regards
Please Log in or Create an account to join the conversation.
- sjscheider
- Topic Author
- Offline
- Platinum Member
- Posts: 40
- Thank you received: 2
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.
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.
- Forum
- Discussions
- QuickOPC-UA in .NET
- Reading, Writing, Subscriptions
- Publishing has halted on the client session