Hi,

Easiest would be to just shut down the server and make another UaServer without the namespaces and start it.

This topic can get really complicated. IF your model is a “leaf namespace” in the dependency hierarchy it is just as simple of deleting all nodes and then removing the manager. However, if not, you must delete all namespaces that depend on this namespace directly or indirectly first. However there is currently no easy way in the SDK to know if a namespace is a “leaf” or not after models have been loaded, but your application layer might “magically know this”.

Since we do have a real node-graph of UaNodes, in the current implementation you must delete the nodes manually so that any references (from nodes that are not deleted) to those nodes are removed. Basically you must call NodeManagerUaNode.deleteNode(node, true, false) for each node in the namespace. NodeManagerUaNode.getNodes() casted to NodeMapUaNode gives NodeMapUaNode.getMap() that gives you Map of the nodes of that manager. Once all are deleted you can use com.prosysopc.ua.server.NodeManagerTable.removeNodeManager(int, boolean), the second parameter controls is the namespace removed from the NamespaceTable (and the server NamespaceArray node updated), note that this was added in somewhat recent SDK and the com.prosysopc.ua.server.NodeManagerTable.removeNodeManager(int) was ambiguous before that (now it an overload that uses ‘true’ for the second parameter). Additionally some clients have had issues with ‘null’ entries in the NamespaceArray, so I recommend setting a placeholder value to that index afterwards.

Note that regradless of that the DataType-related UaDataTypeSpecifications do remain in the EncoderContext and it is not currently possible to remove them. Additionally it should be noted that in OPC UA any existing DataType cannot be altered. For example, you cannot add a field to a Structure. You must make a completely new Structure type with a different NodeId. Unless you control all clients and servers and haven’t published the model. Additionally every change to any VariableType or ObjectType must be backwards-compatible. If not possible, then you must use a different NamespaceUri (with e.g. ‘/v2’).