Please consider registering

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
Durable subscriptions
December 14, 2016
16:35, EEST
Forum Posts: 12
Member Since:
December 6, 2016
sp_UserOfflineSmall Offline

In the OPC Ua specification, Part 4, chapter 6.6, durable subscriptions are described. Is support for durable subscriptions implemented in the Prosys SDK?
Especially storing queues would be necessary to ensure that clients do not miss events even if the server goes down and recovers.
If durable subscriptions are not implemented, is there an alternative mechanism to ensure that events do not get lost on server outages?

December 14, 2016
17:04, EEST
Heikki Tahvanainen

Forum Posts: 402
Member Since:
April 17, 2013
sp_UserOfflineSmall Offline

Hello Reinhard,

Thank you for the question. Durable subscriptions are not supported by the Prosys OPC UA Java SDK. This feature will probably be added in the future.

You could implement similar mechanism by storing the events that you are interested in the server (for example to a database) and then using History Read mechanisms from the client application after the connection break has happened.

June 5, 2019
16:17, EEST
Forum Posts: 12
Member Since:
December 6, 2016
sp_UserOfflineSmall Offline

What is the status regarding durable subscrptions in the current 4.0.x version?

Is there any support? For example, it would be sufficient to have the possibility to get all currently active subscriptions and a possibility to restore those on server start.

June 6, 2019
10:52, EEST
Bjarne Boström
Forum Posts: 365
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline


(Sorry, this is a bit long)

No in that sense that the situation is the same as above, SDK does not contain any specific support for Durable Subscriptions at the moment. You are pretty much the only one who has asked for it.

I would still recommend the same thing Heikki explained above. If there is a use-case that it cannot solve I would like to know.

But in general even if we had support for Durable Subscriptions, I might still suggest going HistoryRead way as it would be easier in most cases.

With both you would need a database, but in the HistoryRead way you will only need to store the actual data (+the NodeId from where it came), with Durable Subscriptions you would need to store all the parameters of the sub + the queue data etc. If you have multiple clients, data storage size is O(1) in HistoryRead (they can share the data), in durable subs I would say it would be O(n) as each would need to store their own queue etc.

However I do agree that if it is not known beforehand which nodes would be used for durable subscriptions, they might be more dynamic than the HistoryRead way, as you would need to configure which nodes are storing history data. However that still would be at most one custom Method (+maybe another to stop), compared to the need that all clients softwares would need to support Durable Subscriptions (they need to call the SetSubscriptionDurable method + some extra requirements mentioned in the 1.04 Part 4 section 6.8). Depending on the data storage needs, it could be easier either way (if you have fixed amount of data per time unit, the db could just periodically delete it, if not then with HistoryRead you might need to call HistoryUpdate to delete it manually + cases with multiple clients could get tricky).

Now then, if you have (a lot of) spare time for experimenting, you could try the following:

Add a CallableListener (like MyMethodManagerListener in the samples) to NodeManagerRoot, intercept (and implement) SetSubscriptionDurable method to avoid Bad_NotImplemented return to clients.

Extend the following classes and methods (non-exhaustive list and some might not be needed):
– UaServer
– createSubscriptionManager
– createSessionManager (not sure if needed, you might need a listener to it)
– SubscriptionManager
– addSubscription
– createMonitoredDataItem
– transferSubscription (fake and create the sub before “transfering” it, or do as part of the Session creation via SessionManager)
– Subscription
– getNextSequenceNumber
– probably all or most of the other protected methods to store data sent to the client
– addDataItem, (you need to call Subscription.addItem for it inside the impl)
– MonitoredDataItem

Note! I have not tested that it is doable, it is very likely that you will hit some roadblock that cannot be solved. You would maybe need to fake some CreateSubscription and CreateMonitoredItemsRequests internally and pass these to the overridden methods.

NOTE! It might be hard or impossible at the moment to put the notifications inside the MonitoredDataItem

If you decide to try implementing, let me know if there are any problems.

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 78

Currently Online:
18 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 89

pramanj: 86

ibrahim: 68

kapsl: 57

gjevremovic: 49

TimK: 41

Fransua33: 39

fred: 36

Rainer Versteeg: 32

peterrob45: 25

Member Stats:

Guest Posters: 0

Members: 841

Moderators: 11

Admins: 1

Forum Stats:

Groups: 3

Forums: 14

Topics: 860

Posts: 3632

Newest Members:

augusthanks, jackbryan, jansmithsmth, uiuida, johnjorge, Ramraj, dimad, aku, Rakshan, claradsouza

Moderators: Jouni Aro: 824, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne Boström: 365, Heikki Tahvanainen: 402, Jukka Asikainen: 1, Teppo Uimonen: 14

Administrators: admin: 0