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-Classic in .NET
- Connections, Reconnections, COM/DCOM
- Connecting to many OPC-servers using multiple threads gives Timeouts
Connecting to many OPC-servers using multiple threads gives Timeouts
24 Sep 2020 15:26 #8944
by support
Replied by support on topic Connecting to many OPC-servers using multiple threads gives Timeouts
Oh, that's great to know. Thank you.
We should either document it somewhere, or think of how to actually automate this in the software itself.
Best regards
We should either document it somewhere, or think of how to actually automate this in the software itself.
Best regards
Please Log in or Create an account to join the conversation.
24 Sep 2020 14:30 #8941
by zaglerp
Replied by zaglerp on topic Connecting to many OPC-servers using multiple threads gives Timeouts
Hello,
when I call ThreadPool.SetMinThreads(60, 60) before reading all the nodes, the operation takes only 5 seconds now.
Thank you, I will set this value in our application as well.
KInd regards
Peter
when I call ThreadPool.SetMinThreads(60, 60) before reading all the nodes, the operation takes only 5 seconds now.
Thank you, I will set this value in our application as well.
KInd regards
Peter
Please Log in or Create an account to join the conversation.
23 Sep 2020 05:59 #8931
by admin
Replied by admin on topic Connecting to many OPC-servers using multiple threads gives Timeouts
Thank you.
One more thing to look at is the .NET thread pool. QuickOPC uses threads from the pool for various things internally. I can imagine that a problem can arise when the demand for threads is significantly higher than the number of threads being provided from the pool. Many threads will then have to wait, and if there are timeouts on the waits, corresponding errors would be returned.
I suggest that you have a look at docs.microsoft.com/en-us/dotnet/api/system.threading.threadpool?view=netframework-4.7.1 , and examine what GetAvailableThreads, GetMaxThreads and GetMinThreads return, and experiment with increasing the value through SetMaxThreads, SetMinThreads.
Best regards
One more thing to look at is the .NET thread pool. QuickOPC uses threads from the pool for various things internally. I can imagine that a problem can arise when the demand for threads is significantly higher than the number of threads being provided from the pool. Many threads will then have to wait, and if there are timeouts on the waits, corresponding errors would be returned.
I suggest that you have a look at docs.microsoft.com/en-us/dotnet/api/system.threading.threadpool?view=netframework-4.7.1 , and examine what GetAvailableThreads, GetMaxThreads and GetMinThreads return, and experiment with increasing the value through SetMaxThreads, SetMinThreads.
Best regards
Please Log in or Create an account to join the conversation.
21 Sep 2020 11:05 #8924
by zaglerp
Replied by zaglerp on topic Connecting to many OPC-servers using multiple threads gives Timeouts
Hello,
one target server per host.
Please have a look at the sample code attached:
UAAttributeDataResult[] attributeDataResultArray = client.ReadMultiple(new[]
{
new UAReadArguments("opc.tcp://10.199.12.51:4840", node),
new UAReadArguments("opc.tcp://10.199.12.52:4840", node),
new UAReadArguments("opc.tcp://10.199.12.53:4840", node),
new UAReadArguments("opc.tcp://10.199.12.60:4840", node),
new UAReadArguments("opc.tcp://10.199.12.61:4840", node),
new UAReadArguments("opc.tcp://10.199.12.62:4840", node),
and so on ...
Kind regards
Peter
one target server per host.
Please have a look at the sample code attached:
UAAttributeDataResult[] attributeDataResultArray = client.ReadMultiple(new[]
{
new UAReadArguments("opc.tcp://10.199.12.51:4840", node),
new UAReadArguments("opc.tcp://10.199.12.52:4840", node),
new UAReadArguments("opc.tcp://10.199.12.53:4840", node),
new UAReadArguments("opc.tcp://10.199.12.60:4840", node),
new UAReadArguments("opc.tcp://10.199.12.61:4840", node),
new UAReadArguments("opc.tcp://10.199.12.62:4840", node),
and so on ...
Kind regards
Peter
Please Log in or Create an account to join the conversation.
21 Sep 2020 11:01 #8923
by admin
Replied by admin on topic Connecting to many OPC-servers using multiple threads gives Timeouts
Hello,
thank you for update.
One more additional question please:
4. Are the target servers always on separate computers (hosts) = one per computer, or are they all on the same host, or how roughly are the servers "distributed" among computers?
Best regards
thank you for update.
One more additional question please:
4. Are the target servers always on separate computers (hosts) = one per computer, or are they all on the same host, or how roughly are the servers "distributed" among computers?
Best regards
Please Log in or Create an account to join the conversation.
21 Sep 2020 09:21 #8922
by zaglerp
Replied by zaglerp on topic Connecting to many OPC-servers using multiple threads gives Timeouts
Sorry for using the wrong forum thread. Is it possible to move it?
Regarding your questions:
1) The exception thrown:
OpcLabs.EasyOpc.UA.UAServiceException: OPC-UA service result - Error establishing a connection: BadRequestTimeout = BadRequestTimeout.
---- SERVICE RESULT ----
Status Code: {BadRequestTimeout} = 0x80850000 (2156199936)
Description: Error establishing a connection: BadRequestTimeout
Status Code: {BadRequestTimeout} = 0x80850000 (2156199936)
Description: BadRequestTimeout
Additional Info: <ExceptionTrace>
---- REMARKS ----
If this error happens during connection to a server: Is the server running and fully operational?
+ The SDK action called was "DiscoveryClient.GetEndpoints".
+ Following (26) events were gathered during the action on activity ID [38], in the order of first occurrence:
SDK trace: GetEndpoints Called. RequestHandle=1, PendingRequestCount=1
SDK trace: Channel 0 in Connecting state.
[57] SDK trace: Channel 0: SendHelloMessage()
3*[59] SDK trace: Channel 0: ProcessAcknowledgeMessage()
3*[59] SDK trace: Channel 0 in Opening state.
[59] SDK trace: Token #0 created. CreatedAt = 09:13:19.490 . Lifetime = 3600000
2*[59] SDK trace: Channel 0: ProcessOpenSecureChannelResponse()
[59] SDK trace: Security Policy: opcfoundation.org/UA/SecurityPolicy#None
[59] SDK trace: Sender Certificate: (none)
[59] SDK trace: Token #1 activated. CreatedAt = 09:13:19.490 . Lifetime = 3600000
[59] SDK trace: Channel 1441275268 in Open state.
[35] SDK trace: Channel 1441275268: Close
[35] SDK trace: Channel 1441275268 in Closing state.
[35] SDK trace: Channel 1441275268: SendCloseSecureChannelRequest()
[58] SDK trace: Channel 0 in Closed state.
[58] SDK trace: CLIENTCHANNEL SOCKET CLOSED: 03A0AAD1, ChannelId=1441275268
[58] SDK trace: Channel 0: SendHelloMessage()
[59] SDK trace: Channel 0: SendHelloMessage()
[59] SDK trace: Token #0 created. CreatedAt = 09:13:21.436 . Lifetime = 3600000
[59] SDK trace: Token #0 created. CreatedAt = 09:13:21.449 . Lifetime = 3600000
[59] *Event list length limit exceeded*
+ Events starting with activity ID in [] may not necessarily be related to the current action.
+ The error occurred when preselecting the endpoint for discovery URL "opc.tcp://10.199.12.78:4840".
+ The client method called was 'ReadMultiple'.
2) It is always the same error
3) For testing I always do a restart of the program. I will try to modify the hold period in my sample.
Kind regards
Peter
Regarding your questions:
1) The exception thrown:
OpcLabs.EasyOpc.UA.UAServiceException: OPC-UA service result - Error establishing a connection: BadRequestTimeout = BadRequestTimeout.
---- SERVICE RESULT ----
Status Code: {BadRequestTimeout} = 0x80850000 (2156199936)
Description: Error establishing a connection: BadRequestTimeout
Status Code: {BadRequestTimeout} = 0x80850000 (2156199936)
Description: BadRequestTimeout
Additional Info: <ExceptionTrace>
---- REMARKS ----
If this error happens during connection to a server: Is the server running and fully operational?
+ The SDK action called was "DiscoveryClient.GetEndpoints".
+ Following (26) events were gathered during the action on activity ID [38], in the order of first occurrence:
SDK trace: GetEndpoints Called. RequestHandle=1, PendingRequestCount=1
SDK trace: Channel 0 in Connecting state.
[57] SDK trace: Channel 0: SendHelloMessage()
3*[59] SDK trace: Channel 0: ProcessAcknowledgeMessage()
3*[59] SDK trace: Channel 0 in Opening state.
[59] SDK trace: Token #0 created. CreatedAt = 09:13:19.490 . Lifetime = 3600000
2*[59] SDK trace: Channel 0: ProcessOpenSecureChannelResponse()
[59] SDK trace: Security Policy: opcfoundation.org/UA/SecurityPolicy#None
[59] SDK trace: Sender Certificate: (none)
[59] SDK trace: Token #1 activated. CreatedAt = 09:13:19.490 . Lifetime = 3600000
[59] SDK trace: Channel 1441275268 in Open state.
[35] SDK trace: Channel 1441275268: Close
[35] SDK trace: Channel 1441275268 in Closing state.
[35] SDK trace: Channel 1441275268: SendCloseSecureChannelRequest()
[58] SDK trace: Channel 0 in Closed state.
[58] SDK trace: CLIENTCHANNEL SOCKET CLOSED: 03A0AAD1, ChannelId=1441275268
[58] SDK trace: Channel 0: SendHelloMessage()
[59] SDK trace: Channel 0: SendHelloMessage()
[59] SDK trace: Token #0 created. CreatedAt = 09:13:21.436 . Lifetime = 3600000
[59] SDK trace: Token #0 created. CreatedAt = 09:13:21.449 . Lifetime = 3600000
[59] *Event list length limit exceeded*
+ Events starting with activity ID in [] may not necessarily be related to the current action.
+ The error occurred when preselecting the endpoint for discovery URL "opc.tcp://10.199.12.78:4840".
+ The client method called was 'ReadMultiple'.
2) It is always the same error
3) For testing I always do a restart of the program. I will try to modify the hold period in my sample.
Kind regards
Peter
Please Log in or Create an account to join the conversation.
04 Sep 2020 07:50 #8858
by support
Replied by support on topic Connecting to many OPC-servers using multiple threads gives Timeouts
Oops. This forum thread is under "QuickOPC-Classic ..." category, not QuickOPC-UA, and therefore I thought we were dealing with OPC "Classic" (I have not looked at your code yet).
No, the "automatic subscriptions" does not exist in/apply to EasyUAClient.
But I need to ask additional questions now.
1. Can you please provide the precise text of the "timeout" error you are referring to, and the associated call stack in the Exception object? And, if there non-null InnerException in it, its message text and call stack, and so on.
2. Is it always the same error, or are there more?
3. As you know, QuickOPC handles connections/disconnection invisibly to the developer. But they still need to be made, and therefore the "first" read on a particular target server is always more demanding than subsequent ones. Is your problem/your test done after a fresh start of the program, or does it behave the same upon subsequent reads? Also note that the default setting is to disconnect in several seconds after last use, if there are no subscriptions, so after that period elapses, QuickOPC disconnects and a new connection is needed again; it might be wise to increase this "hold period" in heavily loaded systems, where operations themselves take long, to prevent unwanted disconnections/reconnection which further contribute to the load.
Regards
No, the "automatic subscriptions" does not exist in/apply to EasyUAClient.
But I need to ask additional questions now.
1. Can you please provide the precise text of the "timeout" error you are referring to, and the associated call stack in the Exception object? And, if there non-null InnerException in it, its message text and call stack, and so on.
2. Is it always the same error, or are there more?
3. As you know, QuickOPC handles connections/disconnection invisibly to the developer. But they still need to be made, and therefore the "first" read on a particular target server is always more demanding than subsequent ones. Is your problem/your test done after a fresh start of the program, or does it behave the same upon subsequent reads? Also note that the default setting is to disconnect in several seconds after last use, if there are no subscriptions, so after that period elapses, QuickOPC disconnects and a new connection is needed again; it might be wise to increase this "hold period" in heavily loaded systems, where operations themselves take long, to prevent unwanted disconnections/reconnection which further contribute to the load.
Regards
Please Log in or Create an account to join the conversation.
03 Sep 2020 15:09 #8852
by zaglerp
Replied by zaglerp on topic Connecting to many OPC-servers using multiple threads gives Timeouts
Hello,
we are using UA - is it the same for the UA client?
Kind regards
Peter
we are using UA - is it the same for the UA client?
Kind regards
Peter
Please Log in or Create an account to join the conversation.
03 Sep 2020 13:42 #8847
by support
Replied by support on topic Connecting to many OPC-servers using multiple threads gives Timeouts
Hello,
I admit that we have not tested with such large numbers of servers. The recommendations I gave were based on the knowledge of internal design and implementation.
Looking at the results of your tests, I think that there is a possibility that additional functionality inside EasyDAClient (so-called automatic subscriptions) is responsible for (at least parts) of it. Can you please do the steps described here and re-test?:
www.opclabs.com/forum/reading-writing-subscriptions-property...scriptions-made-with-opc-reads
Also note that if the problem was the timeout error, but not the long time by itself, the timeout values can be configured to be longer.
Best regards
I admit that we have not tested with such large numbers of servers. The recommendations I gave were based on the knowledge of internal design and implementation.
Looking at the results of your tests, I think that there is a possibility that additional functionality inside EasyDAClient (so-called automatic subscriptions) is responsible for (at least parts) of it. Can you please do the steps described here and re-test?:
www.opclabs.com/forum/reading-writing-subscriptions-property...scriptions-made-with-opc-reads
Also note that if the problem was the timeout error, but not the long time by itself, the timeout values can be configured to be longer.
Best regards
Please Log in or Create an account to join the conversation.
03 Sep 2020 12:30 #8844
by zaglerp
Replied by zaglerp on topic Connecting to many OPC-servers using multiple threads gives Timeouts
Hello!
In our case we have to communicate with more than 100 servers and the startup time of the client now exceeds 6 minutes, when using MultipleRead().
We also experience Timeouts, although al servers are up and running.
Can you please explain, what we can do to reduce it and how to avoid the Timeout situations?
I have attached a simplified sample showing the results using different approaches for initiating the communication:
Test1: (Main1)
Accessing 28 servers with one call to ReadMultiple()
Duration: 51 sec. 2 Timeouts
Test2: (Main2)
Accessing 28 servers with subsequent calls to single Read()
Duration: 22 sec. No timeouts
Test3: (Main3)
Accessing 28 servers with subsequent calls to single Read() having a delay of 100ms:
Duration: 5 sec, No timeouts
Thank you for your support.
Peter
In our case we have to communicate with more than 100 servers and the startup time of the client now exceeds 6 minutes, when using MultipleRead().
We also experience Timeouts, although al servers are up and running.
Can you please explain, what we can do to reduce it and how to avoid the Timeout situations?
I have attached a simplified sample showing the results using different approaches for initiating the communication:
Test1: (Main1)
Accessing 28 servers with one call to ReadMultiple()
Duration: 51 sec. 2 Timeouts
Test2: (Main2)
Accessing 28 servers with subsequent calls to single Read()
Duration: 22 sec. No timeouts
Test3: (Main3)
Accessing 28 servers with subsequent calls to single Read() having a delay of 100ms:
Duration: 5 sec, No timeouts
Thank you for your support.
Peter
Please Log in or Create an account to join the conversation.
Moderators: support
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Connections, Reconnections, COM/DCOM
- Connecting to many OPC-servers using multiple threads gives Timeouts
Time to create page: 0.091 seconds