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
- Connections, Reconnections, Certificates
- BadSessionClosed causes disconnect and reconnect of server when subscribing
BadSessionClosed causes disconnect and reconnect of server when subscribing
Best regards
Please Log in or Create an account to join the conversation.
Found the KeepAliveInterval, KeepAliveIntervalDebug and SessionTimeout under EasyUaClient.IsolatedParameters.SessionParameters, but did not find SessionTimeoutDebug. Is that located somewhere else? Not very important as long as this works as expected in "Release" mode, but would be beneficial to set the parameters in code to avoid new developers debugging the same problem once more.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Yes, it has to do with the keep-alive mechanism on the UA session level. The client does not call the server soon enough, and the server reacts as it should - by closing the session.
In UAClientSessionParameters, we have the parameters listed further below to control the related time intervals. There are two sets - one is for normal operations, and the other is for debugging (when QuickOPC detects that the debugger is attached). The reason for the separate debugging set is that once the users starts setting breakpoints, the normal intervals (that are in order of magnitude such as seconds or tens of seconds) are not enough to keep the communication up, it breaks, and the debugging becomes impossible. The values below are as of QuickOPC 2018.3.
For normal operations:
- SessionTimeout - tells the server the maximum interval the client can stay "silent" - defaults to 1 minute
- KeepAliveInterval - tells the client how often it performs keep-alive operations to the server - defaults to 5 seconds
- SessionTimeoutDebug: defaults to 10 minutes
- KeepAliveIntervalDebug: defaults to 1 day
The KeepAliveInterval should always be smaller than SessionTimeout. As you can see from the list above, it is basically wrong in the debugging mode, as it is longer. Ideally, we would like to make the SessionTimeoutDebug also very long, and indeed it used to be like that, but there is additional problem: Sessions with such long timeout may accumulate on the server (as it takes so long to detect that the session is gone), and cause problems on the server side. So, we have reduced the SessionTimeoutDebug to a compromise value between a comfortable debugging experience, and acceptable server load, but basically forgot to also reduce the KeepAliveIntervalDebug.
The resolution is simple: Set the values above to what is needed for your application, but always making sure the keep-alive interval is smaller than the session timeout (I recommend no more than 25% of the session timeout).
In the future version we will fix this, so that the client won't actually ever use a keep-alive interval longer than session timeout, even if instructed to do so.
There is only one thing I do not quite understand from the log files, and that is, that I am seeing a session timeout actually being 1 minute (not 10 minutes); but the keep-alive interval is indeed 1 day. Maybe you have already changed the value of the session timeout; I am not sure how this could have happened. But the analysis above is probably still right.
Best regards
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
But, I cannot tell more without doing the analysis of the communication.
Best regards
Please Log in or Create an account to join the conversation.
Looks like the problem is related to connections to servers where subscribed values do not change its value for some time. If I subscribe to a value changing regularily I do not get disconnected.
Is this not related to keepalive, timeouts and other related parameters? Could you recommend a setting for connection parameters? OPC values will in our case be used for monitoring a critical process and we can not live with long reconnect periods (or regular disconnects). Is there a form of "server ping" functionality?
Thanks.
Please Log in or Create an account to join the conversation.
Note: All servers are of the same Siemens NET servers.
Will try to get some more logs.
Please Log in or Create an account to join the conversation.
I have seen similar behavior in the past. Usually, I have found the the server is reporting an error for a reason that could not be explained from the network communication. Reported it to the server vendor, got no response => there was no resolution.
Best regards
Please Log in or Create an account to join the conversation.
192.168.23.249: 43 items
192.168.23.211: 58 items
192.168.23.212: 8 items
192.168.23.61: 769 items
192.168.23.50: 37 items
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-UA in .NET
- Connections, Reconnections, Certificates
- BadSessionClosed causes disconnect and reconnect of server when subscribing