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

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.

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

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

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