Log In
Register
Forum
Topic RSS
14:37, EEST
June 27, 2012
Offline
I have multiple custom NodeManagers based on BigNodeManager, and I want to be able to make one of them go away dynamically.
I suppose I could just stop reporting all of the references and info about the nodes it controls, but it seems like there’s probably a better way to do this.
What’s the best practice here?
15:32, EEST
December 21, 2011
Offline
That’s a good question 🙂 Which means that I do not have a very good answer at hand.
Biggest problem is, if you have references to your nodes from other node managers – or from monitored items. In which case it is a bit uncertain what will actually happen.
But you might be able to just remove the NodeManager from NodeManagerTable (available from UaServer). It’s NamespaceURI will be kept in the NamespaceTable, so the indexes should not change, but the nodes will not be found any more.
Please, let us know how you manage with it.
19:10, EEST
June 27, 2012
Offline
Heh, that’s not the answer I was hoping for 🙂
I’m not worried about references from other node managers, each of mine will be self-contained.
What about calling beginModelChange() and then deleteNode()? Does that handle monitored items?
Is there no way within the spec to tell the client that a node went away?
8:53, EEST
December 21, 2011
Offline
Oh yes, that is the correct way to tell the clients that the nodes have been deleted. The specification defines that you must support the NodeVersion property for objects, before you should send ModelChange-events, though. And you must increase the NodeVersion value for each affected node when the event is sent.
The SDK updates the NodeVersion automatically for UaNode-based nodes (which have initialized the NodeVersion, e.g. by calling BaseNode.initNodeVersion()) and also ensures that changes related to such nodes are included in an open ModelChange.
You will need to do that yourself with your own nodes and you can use these NodeManagerRoot-methods:
beginModelChange() opens a model change,
addModelChange() adds changes to an open one
endModelChange() triggers the event (remember to update the NodeVersion).
or you can just construct the GeneralModelChangeEventType object yourself.
The event is reported always for the Server object (whole address space) or a View Node.
14:56, EEST
June 27, 2012
Offline
It looks like this would work – I could start a model change, and then send NodeDeleted model changes for each node.
How would updating the NodeVersion work if I deleted the node? It wouldn’t have the property anymore, right? I guess I would need to have the property in the first place, so that the client expects the model change events on that node, but I don’t see how getting a new value of the property would work when the node has disappeared.
The other issue I see is that I would have to send a LOT of NodeDeleted events. The reason I’m creating a custom node manager in the first place is the large # of nodes in the namespace – I could have several hundred thousand, so it seems like that could be a pretty big performance/network issue. Is there a way to say that a whole tree was deleted from the namespace? I suppose I could just send notifications for the subscribed values, and then maybe send another notification if any of the other deleted values are requested later?
6:38, EEST
December 21, 2011
Offline
Yes, I was wondering about that too. I had got this so that you could just define the NodeVersion for some top level objects and then notify that they are deleted, which should imply that the complete structure has been removed under it.
The Monitored Items can be treated also by sending a Bad_NodeIdUnknown status for them to imply that the nodes have been removed.
16:37, EEST
December 21, 2011
Offline
I asked some advice from other experts and it seems that the correct strategy is indeed to define NodeVersion only for a reasonable number of objects, for example, for devices that have a known structure – or if that seems too much, for even higher level nodes.
For each node that has NodeVersion, you should add a NodeDeleted + ReferenceDeleted plus one ReferenceDeleted for the (or each) node that has a reference to the deleted node.
If you still suspect that this will make a too big ModelChange message, you may considering breaking it to several smaller once (one for every 1000 devices, for example), to ensure that the message does not exceed the message size limits of the UA stack at either end (server or client).
But you have free control over it by defining NodeVersion only to nodes that you consider to really need the notification.
Most Users Ever Online: 518
Currently Online:
15 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
hbrackel: 135
pramanj: 86
Francesco Zambon: 81
rocket science: 77
Ibrahim: 76
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
fred: 41
Member Stats:
Guest Posters: 0
Members: 681
Moderators: 16
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1467
Posts: 6261
Newest Members:
graciela2073, sagarchau, elviralangwell4, Donnavek, Eddiefauth, DonaldPooma, fidelduke938316, Jan-Pfizer, DavidROunc, fen.pang@woodside.comModerators: Jouni Aro: 1010, Otso Palonen: 32, Tuomas Hiltunen: 5, Pyry: 1, Petri: 0, Bjarne Boström: 983, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 26, Teppo Uimonen: 21, Markus Johansson: 42, Niklas Nurminen: 0, Matti Siponen: 321, Lusetti: 0, Ari-Pekka Soikkeli: 5
Administrators: admin: 1
