Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
subscription lost after communication fault
February 19, 2021
11:36, EET
Avatar
ibrahim
Member
Members
Forum Posts: 75
Member Since:
August 20, 2014
sp_UserOfflineSmall Offline

Hi,
we are using ua-client-server-sdk-4.0.2-808.
Our client application for unknown reasons does no longer receive datachange events after a communikation fault. If we recignize a communication fault we renew all subscriptions, but still it can sometimes happen, that we dont receive changes any more. Our session to the server is still active, because we can still read and write, only the data change subscription is gone. We also analysed the server when we are in that state with UaExpert. We could see that in the servers sessions diagnostics we can find our session, but the subscription is emtpy. We dont understand how we can come into this state. Could you please support us what we can do to find out what is the root cause for this?

Thanks in advance.

Ibrahim

February 19, 2021
12:21, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 982
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

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.

June 7, 2022
17:10, EEST
Avatar
Jeremy Morgan
Member
Members
Forum Posts: 15
Member Since:
November 6, 2019
sp_UserOfflineSmall Offline

We have had a similar issue, but we are using Prosys-OPC-UA-Java-SDK-Client-Binary 4.0.0-774

Looking at the log files, I see a change of state from ‘Running’ to ‘CommunicationFault’ then almost immediately back to ‘Running’ (via ServerStatusListener.onStateChange()). This all happens in around 140ms. Following this there are no more Subscription data change notifications, even though an independent check with a standalone client shows the tags are changing.

We have UaClient.setStatusCheckInterval() set to 60s, and UaClient.setStatusCheckTimeout() not set which I believe defaults to 10s.

There are no Subscription timeouts reported (all the Subscriptions have a SubscriptionAliveListener). We have the setAutoReconnect() set to true on the UaClient.

To re-establish data collection we have to stop and restart our application.

Any suggestions as to how we can fault-find this?

June 8, 2022
8:35, EEST
Avatar
Matti Siponen
Moderator
Members

Moderators
Forum Posts: 319
Member Since:
February 11, 2020
sp_UserOfflineSmall Offline

Hello,

Version 4.0.0 is already very old. In addition to new features, bug fixes and other improvements, there are also several critical security fixes and thus updating to 4.8.0, the latest version at the moment, would be highly recommended. See the release notes for more information: https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html

Does the communication fault involve the Server restarting itself? If it does, there is a chance that it allows Clients to connect before it has added all Nodes to its AddressSpace. If a Client would attempt to create MonitoredItems at such stage, it would fail with StatusCode Bad_NodeIdUnknown and receiving DataChangeNotifications would stop until the Client is reconnected or restarted manually. Clients using older versions of the SDK would not try to retrying creating MonitoredItems in such scenarios automatically, but in newer versions of the SDK that is attempted periodically.

If the communication fault does not involve the Server restarting itself, we would need to see logs from the Client and the Server applications to identify what is happening before and after the communication fault.

You can also use Wireshark to find out what a Client and a Server are doing around the time of the communication fault, but installing it to your environment may or may not be allowed depending on your company policies. See https://www.prosysopc.com/blog/opc-ua-wireshark/ for instructions on how to capture OPC UA communication with Wireshark. If you’re running the applications on the same host, remember to select “Support loopback traffic” option when installing Wireshark.

June 14, 2022
18:03, EEST
Avatar
rocket science
Member
Members
Forum Posts: 75
Member Since:
March 16, 2017
sp_UserOfflineSmall Offline

Matti Siponen said
Clients using older versions of the SDK would not try to retrying creating MonitoredItems in such scenarios automatically, but in newer versions of the SDK that is attempted periodically.

With which SDK version is it attempted periodically in case the items or subscription failed after connect?

June 15, 2022
7:59, EEST
Avatar
Matti Siponen
Moderator
Members

Moderators
Forum Posts: 319
Member Since:
February 11, 2020
sp_UserOfflineSmall Offline

rocket science said

Matti Siponen said
Clients using older versions of the SDK would not try to retrying creating MonitoredItems in such scenarios automatically, but in newer versions of the SDK that is attempted periodically.

With which SDK version is it attempted periodically in case the items or subscription failed after connect?  

Hello,

The functionality for attempting to recreate MonitoredItems with error code Bad_NodeIdUnknown has been in the SDK since version 4.6.0 but it was disabled by default and had to be enabled for a Subscription by calling subscription.setRecreateFailedItems(true). In the latest release of the SDK, version 4.8.0, this functionality is enabled for all Subscriptions by default.

February 6, 2023
20:56, EET
Avatar
Jeremy Morgan
Member
Members
Forum Posts: 15
Member Since:
November 6, 2019
sp_UserOfflineSmall Offline

We are now running 4.8.0-25 but still seeing the same issue on site.
When it happens we typically see ServerStatusListener.onStateChange() get called with the state changing from ‘Running’ to ‘Communication Fault’.
Then about a second later it changes back from ‘Communication Fault’ to ‘Running’.
However from this point onwards we get no more Subscription data change notifications i.e. MonitoredDataItem.onDataChange() does not get called.
To fix this we have to restart the Application.
Previously, we were on an older version, so the suggestion was to upgrade to a newer version, which we have done.
I’ve looked at the changelog for 4.8+ but can’t see any references in newer SDK versions to anything that resembles this issue.
Any ideas?

February 7, 2023
13:32, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 982
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

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?

February 9, 2023
18:50, EET
Avatar
Jeremy Morgan
Member
Members
Forum Posts: 15
Member Since:
November 6, 2019
sp_UserOfflineSmall Offline

It’s difficult to use Wireshark as this is on a customer’s site.

I am letting the SDK handle any reconnections and re-subscriptions that are necessary.

I will update to 4.10 and add in the listeners.

Is it possible to check what subscriptions the OPC server currently has registered using an external tool such as the Prosys OPC UA Browser?

February 10, 2023
9:51, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 982
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

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.

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 518

Currently Online:
14 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 135

pramanj: 86

Francesco Zambon: 81

ibrahim: 75

rocket science: 75

Sabari: 62

kapsl: 57

gjevremovic: 49

Xavier: 43

fred: 41

Member Stats:

Guest Posters: 0

Members: 707

Moderators: 16

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1465

Posts: 6252

Newest Members:

christi10l, ahamad1, Flores Frederick, ellenmoss, harriettscherer, shanonhumphreys, KupimotoblokfuB, tamhollander5, paulinafcf, bridgette18l

Moderators: Jouni Aro: 1009, Otso Palonen: 32, Tuomas Hiltunen: 5, Pyry: 1, Petri: 0, Bjarne Boström: 982, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 26, Teppo Uimonen: 21, Markus Johansson: 42, Niklas Nurminen: 0, Matti Siponen: 319, Lusetti: 0, Ari-Pekka Soikkeli: 5

Administrators: admin: 1