Hi,

Is the server made with our SDK or something else?

Please be a bit more specific with what you mean with “renew all subscriptions”? With defaults, the SDK would do that automatically (to a degree). If you are doing that in addition manually, the id’s that define the items might get mixed etc.

I would assume you let the SDK handle the reconnecting (this is the default) and are not manually calling UaClient.reconnect(). In SDK 4.3.0 we added a WARN log if this is made (manual call while the automatic reconnecting is enabled). A better solution is hopefully made in the future.

Anyway, Subscriptions live independently from Sessions. While Subscriptions are made in a context of a Session, they can be transferred to another one. An active Session prevents subscriptions from timing out in the serve side by sending PublishRequests, which the server responds data or keepalives if nothing to send. If because of a connection break no publishrequest arrives within LifetimeCount*PublishInterval, the server will delete the Subscription.

If UaClient notices a communication break, it will go into a “reconnect mode”. Once connection resumes, if the old session cannot be used, it will make a new one and tries to transfer the Subscriptions to it. If that fails it will try to recreate them (if this fails, there is limited automatic error handling).

An SubscriptionAliveListener can be set to the client side subscriptions, it’s onTimeout and onLifetimeTimeout will be called by the SDK if a keepalive was not received when expected and when it can be expected that the server would have deleted the subscription, respectively. In general, both cases could be taken as an error scenario, that preferably should not happen. However, if the connection resumes before the lifetime runs out, then the onTimeout wont matter. Both calls are calculated on the client side based on the timings when we should have received a keepalive.

SDK currently cannot recover automatically from a scenario that if we do not detect a communication break (i.e. we keep getting the ServerStatus via Read), but the server would still fail to send us a keepalive or data. That could be detected with SubscriptionAliveListener, but I do recognize, that the situation is not optimal, since those would also get called eventually in a connection break scenario.

Any chance to get https://www.prosysopc.com/blog/opc-ua-wireshark/ capture of the problem or log files? If possible, you can send them to uajava-support@prosysopc.com.

4.10.2 added MonitoredItemErrorListener, which could be used to monitor the status of the item creation; that might be useful. You could also check MonitoredItem.getErrorCode() manually, what is this status (a bit after the reconnection has happened or when you clearly note that you are not receiving data)? What is MonitoredItem.getInitialStatus()?

Nowadays (from SDK 4.8.0+) the SDK by default will try to re-create MonitoredItems that have previously succeeded, but are failing with Bad_NodeIdUnknown after a reconnect. Some servers have their endpoints up before their address space, thus that caused some problems. Though that is the only code for which this happens at the moment (this is a bit hard situations as we also try to avoid making an infinite retry).

I assume you are not doing anything like manually disconnecting and then connecting again etc. so you just let the SDK to handle the reconnections automatically?

If the server supports OPC UA Diagnostics, they can be viewed in nodes below Root/Objects/Server/ServerDiagnostics/*. Typically they are not enabled by default though, you might be able to do that by writing true to /Root/Objects/Server/ServerDiagnostics/EnabledFlag (or some server-specific way, conf files etc.), but note that it might (and probably will) affect performance so ask the customer first.

However, I’m not 100% sure how useful that is because most likely the subscription creation itself has succeeded, but the items failed, so in this case at best I think you would just see the subscription there with 0 in MonitoredItemCount in the diagnostics (assuming the server supports that specific diagnostic value, if not it could also just be 0 always).

Thus the 4.10.2 MonitoredItemErrorListener (or checking the value manually in earlier versions) probably gives more information on how to proceed with this.