Great, thanks for letting me know.

Ad 2, Ad 4. The purpose of the keep-alive mechanism is to *detect* problems. The interval has nothing to do with what happens *after* the problem is detected.

To your requirement "reconnect max 2 seconds after disconnection": I must repeat, your ongoing attempts to make everything as fast as possible are only going to make things worse. The parameters should be set up in such a way, that short interruptions do not case disruptions. If there *is* a true communication problem, such as network broken, or the server is down, setting the client to make reconnection attempts every hundreds of milliseconds, or each 1 second, is not going to resolve the problem. It is only going to put unnecessary stress on anything on the client side, and possibly (depending on the situation - e.g. of the network is OK but it is the server that is undergoing some restart or reconfiguration) also on the server side.

Stop tuning the parameters to "fast" levels just because that's the instinctive reaction.

Regards

Hello,

I have found the reason for “The OPC-UA subscription publishing has stopped.”. It is a genuine error: That it, the keep-alive mechanism has properly detected the situation. The problem is that the mechanism is probably too sensitive.
Here is what happened, coming from the logs you have sent and the situation around 10:17:55:

You have subscriptions where the publish interval is 100 milliseconds (probably automatically derived from a sampling rate of 200 milliseconds). The default keep-alive count we request from the server is 10, and the server did not revise it. This means that, in order to prove that the subscription is working, the server should deliver a response (a PublishResponse) no later than in 10*100 milliseconds = 1 second, even if there is no data change.

In the logs, this has been true until around 10:17:55. Then, it took over 1 second between PublishRequest (Wireshark frame #8998) and PublishResponse (#9082), and again between #9083 and #9093. This could be due to various factors: Resource stress on the server, client, or the network. Probably not on the client computer (I can tell that because our own reaction own, e.g. between frames #9082 and #9082, does not appear significantly slower as in other cases). Certainly things that we cannot directly influence. But it is nothing critical: The times were not drastically over 1 second. This means that the detection mechanism is just too sensitive.

The probability that this happens increases with faster publish interval (sampling rates), and yours is relatively high. With them using a keep-alive count of 10 is probably not enough; it should be higher. This can be resolved in two ways:
1) On the server: The server can revise it; there is a provision for it in OPC UA Specs. In my view, that would be the most appropriate thing technically, because the “inability to keep up with such pace” is more on the server side. The server can do it the code, or they can have some configurable setting for it.
2) On the client: We can request a higher keep-alive count (and hope that the server won’t revise it to a lower number; most likely not).

With QuickOPC 5.32 that you are using, the keep-alive count requested by the client is fixed to 10 and you cannot change it.
You can (and should), however, download QuickOPC 5.34, and rebuild your project with it. This will bring you two things:

A) Ability to change the keep-alive count. There is now a UAClientSubscriptionParameters.KeepAliveCount for it.
But most likely you will not need to touch this property either, because we now have a minimum keep-alive interval built in, and that is set to 5 seconds normally, and to 1 day when a debugger is detected. If needed, we bump-up the KeepAliveCount to higher number so that the keep-alive interval is never longer than these minimums.

In other words, just rebuild with version 5.34, and re-test then.

Other notes – not related to the issues you reported:
- Are you doing some BrowseXXXX calls on the EasyUACLient with fast subscriptions? (it appeared like that from the logs). If so, even though they are only at the beginning, I recommend using an isolated client for them as well.
- Are you repeatedly calling SubscribeMonitoredItem, instead of making one big call to SubscribeMultipleMonitoredItems? If so, consider changing it, for efficiency.

To your last post:

Zero is not valid for RetrialDelay. I suggest you have it set to at least 500 milliseconds, ideally more, at least several seconds. Remember that it handles a situation which should NOT happen, and our task is to prevent that situation - for which I have described the recommended solution above. Setting the retrial to low value goes against its purpose.

Best regards
Zbynek Zahradnik

Hello,
At least I know where the 3 minutes delay comes from:

At 10:17:55, “The OPC-UA subscription publishing has stopped.”. I am still investigating why.
The consequence of it is that you stop receiving updates for this subscription, we delete the subscription, wait for 3 minutes, and then try to re-create it.

The delay can be configured as follows (default is 3*60*1000):
Obviously that’s not meant as a solution. The true problem is why this whole re-connection mechanism has been triggered, i.e. why the “The OPC-UA subscription publishing has stopped.”. Working on it.

Best regards,