Professional OPC
Development Tools

logos

BadSessionClosed causes disconnect and reconnect of server when subscribing

More
11 Mar 2019 13:00 - 11 Mar 2019 13:01 #7194 by support
You are right. I made a mistake by looking into the code of the upcoming version (2019.1) already. There is no SessionTimeoutDebug in the versions released so far (till 2018.3). SessionTimeout is used in these versions, whether debugger is attached or not. This also explains why your SessionTimeout is 60000, even with debugger attached.

Best regards
Last edit: 11 Mar 2019 13:01 by support.

Please Log in or Create an account to join the conversation.

More
11 Mar 2019 12:40 #7193 by veda
Thank you for your detailed response. Can confirm that you found the issue. When running the client without debugger attached the client does not get disconnected. And also, as you described, if there are traffic in the form of variable updates we do not see any disconnects.

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.

More
09 Mar 2019 20:39 #7190 by support
One additional piece of information: The problem only occurs if there is no other communication on the session. This explains why there may be no problems with other servers. If you call any OPC operation from the client side soon enough, OR if the subscribed values are actually changing, there is a communication between the client and the server going on (the client responds to tell the server it has received the changed values), and the session won't time out on the server that easily as if there is just one value and it does not change.

Please Log in or Create an account to join the conversation.

More
09 Mar 2019 20:36 #7189 by support
Thank you. The logs were very useful. I think I have identified the cause of the issue.

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
When debugger is attached:
  • 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.

More
06 Mar 2019 14:11 #7180 by veda

Please Log in or Create an account to join the conversation.

More
25 Jan 2019 06:51 #7038 by support
Yes, this can be related to the keepalive etc. mechanisms. But the server and client negotiate the various timing parameters. If this went somehow wrong, it could manifest itself in this way.

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.

More
24 Jan 2019 07:43 #7031 by veda
Did a couple more tests after viewing this post: www.opclabs.com/forum/ua-live-binding-and-mapping/2218-badsessionidinvalid

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.

More
23 Jan 2019 14:45 #7028 by veda
Have done some more tests. Found that the issue is related to one of the servers. I get the same issue when just subscribing to one value of this server. The strange thing on the full application is that the client disconnects from all servers when it detects problem with this spesific server.
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.

More
23 Jan 2019 08:51 #7027 by support
This would probably need a Wireshark capture, and associated information, to troubleshoot. See kb.opclabs.com/Collecting_information_for_troubleshooting . With as few as possible variables/server, in order to make the analysis easier.

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.

More
22 Jan 2019 13:09 #7019 by veda
I am only subscribing to monitored items with sampling interval of 200ms. I am subscribing to total of 915 variables divided by the following servers:

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.

Moderators: support
Time to create page: 0.264 seconds

      

 Recommend this on Google