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.
The client appears to have stopped running
Regards
Please Log in or Create an account to join the conversation.
EasyUAClient.AdaptableParameters.SessionParameters.ServerShutdownRetrialDelay = 5minutes
EasyUAClient.AdaptableParameters.SessionParameters.EndpointSelectionTimeout
EasyUAClient.AdaptableParameters.SessionParameters.SessionConnectTimeout
EasyUAClient.AdaptableParameters.SessionParameters.OperationTimeout
EasyUAClient.AdaptableParameters.SessionParameters.CloseTimeout
Please Log in or Create an account to join the conversation.
1) After 2-3 months of actual operation observation, the problem has been basically solved at present
2) The reason is basically determined to be caused by the default connection parameter of QuickOpc's driver (EasyUaClient)
3) Scenario: The client connects to more than 10 machines normally, completes subscribing to multiple locations, and then the ServerConditionChange shows as disconnected. When EasyUaClient is reconnected, the organic rate thread count slowly increases. When multiple machines and locations are disconnected at the same time, after about 2-4 hours, the thread count reaches the 2000 limit
4) Solution: Modified the reconnection interval control
5) At present, such anomalies have not occurred again
6) Regarding this issue, it first appeared after December 27, 2023, when another problem was modified (the issue of delayed issuance from other machines caused by disconnection and reconnection)
www.opclabs.com/forum/ua-connections/3667-quickopc-reconnect-problem#12495
7) So far, QuickOpc has basically solved several major problems in my project practice.
Thanks
2024.8.6 17:17
Please Log in or Create an account to join the conversation.
The reconnection settings you are doing appear correct. I have tested them, by modifying the basic subscription examples we have, and they worked for me. So, it looks like that there must be something else different in your program that causes the reconnections to behave differently. The recommendation is to start with a simple program like did, test the reconnections, and then gradually look for what is done differently in the real program.
However, there are some changes and fixes in the current version that may affect you, and I would highly recommend that you switch to the current QuickOPC version (5.80.278 or later). There was nothing made to address specifically your problem, but there were changes and fixes in the related areas. For example, we fixed a problem in which the faulted connection was not reported through DataChangeNotification quickly enough (it could take up to the reconnection delay before it was reported).
Regards
Please Log in or Create an account to join the conversation.
Hi ,support:
Review current issues
1) During the operation of the client, when the machine is disconnected, there is a connection exception that causes the thread to become larger, ultimately reaching the maximum thread pool limit ( ThreadPool Max Count: 2000)
2) has manually set the time interval for retry connections. For example, I set the interval to 5 minutes, but in reality, the connection is reconnected after 20 seconds. Please refer to the attached screenshot
3) I now want OpcUAclient to try reconnecting every five minutes for disconnected machines. How do I configure the parameters ?
current setting:
"RetryConnectDelay": 300,
"EndpointSelectionTimeout": 15000,
"SessionConnectTimeout": 60000,
"OperationTimeout": 120000,
"CloseTimeout": 5000,
easyUAClient.IsolatedParameters.SessionParameters.RetrialDelay = 300 * 1000;
EasyUAClient.AdaptableParameters.SessionParameters.RetrialDelay = 300 * 1000;
Simon
2024.7.5 16:03
Please Log in or Create an account to join the conversation.
Review current issues
1) During the operation of the client, when the machine is disconnected, there is a connection exception that causes the thread to become larger, ultimately reaching the maximum thread pool limit ( ThreadPool Max Count: 2000)
2) has manually set the time interval for retry connections. For example, I set the interval to 5 minutes, but in reality, the connection is reconnected after 20 seconds. Please refer to the attached screenshot
3) I now want OpcUAclient to try reconnecting every five minutes for disconnected machines. How do I configure the parameters ?
current setting:
"RetryConnectDelay": 300,
"EndpointSelectionTimeout": 15000,
"SessionConnectTimeout": 60000,
"OperationTimeout": 120000,
"CloseTimeout": 5000,
easyUAClient.IsolatedParameters.SessionParameters.RetrialDelay = 300 * 1000;
EasyUAClient.AdaptableParameters.SessionParameters.RetrialDelay = 300 * 1000;
Simon
2024.7.5 16:03
Please Log in or Create an account to join the conversation.
While I do not know the concrete cause of your issues, it should be said that in case of *excessive* network problems, there are scenarios that are effectively impossible to handle gracefully. QuickOPC tries to reestablish the connections (which is ultimately what users want) when a problem is detected on the OPC UA level. But at the same time, there can still be TCP connection "leftovers" (such as unclosed connections) that take long time to close and clean up (and we depend on the system and the UA stack in this respect). If the network problem occurs rarely, this is OK - eventually the "leftovers" will be cleaned up. But if the network problem repeats, a buildup of the "leftovers" can occur.
Regards
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
The following information is recently collected
Part A :
Regarding the issue of stopping production in this specific situation, a lot of tests have been conducted recently, and the environment is as follows:
1.1 We used 5 physical machines and simulated 12 VM virtual machines. Each virtual machine was templated with an opcServer (Kepserver) and imported 300 points,
1.2 There are a total of 12000 point configurations, of which 30 points are written back per second. Finally, a client. exe (EaseyUaClient) is used to connect simultaneously
1.3 Using unplugging the network cable, modifying the point path (simulating batch point not saving), and shutting down the virtual machine, after repeated attempts, the problem could not be reproduced, and finally abandoned this simulation.
Part B:
1) Has been on the actual project site recently, with more than 30 clients in total, and a few of them have encountered anomalies again. I have conducted corresponding information collection
2) I have monitored the number of threads on each client. exe (EasyUAClient) end, and there is a slow growth of client threads, ranging from exceptions to reaching the upper limit, which takes about 1-4 hours before and after;
3) I extracted the dump document and opened and analyzed it using VS2022, with clear exception prompts
4) There are more than 1920 threads queuing, all waiting for another thread. I will delay taking a screenshot of the code location
5) The code for the most internal waiting;
dump debugger:
[24256] NET ThreadPool Worker =>
UaSCUaBinaryClientChannel. cs=> line 265
1==>writeOperation End (int. MaxValue);==>// here....
Opc.Ua.Core.dll Opc.Ua.Bindings.ChannelAsyncOperation at line 185
2=>if (! M event. WaitOne (timeout)&&throwOnError) //here: WaitOne (timeout)
at same time : 1,978 Threads blocked at same code line
I Think , may be timeout too largue,retry interval too small
I noticed the target m event Set() is related to timeout, I am trying to adjust the parameters
EndpointSelectionTimeout = 15* 1000
SessionConnectTimeout=15 * 1000
OperationTimeout=10 * 1000
CloseTimeout=5 * 1000
RetryConnectDelay=60*1000
Please Log in or Create an account to join the conversation.
It might not even be possible to resolve problem without having a reproducible scenario in our lab. That would require you to put together a VM/VMs for the repro, which we can then run here and put on them our debug versions and debug tools.
Aside from that, we can try to figure out something using remotely collected information, but that is a long shot. First thing needed is the one I described in my last post, i.e. obtain the stack traces from the blocked application.
Regards
Please Log in or Create an account to join the conversation.