Replies: 3 comments 15 replies
-
|
I think we're in general open for improvements to the code, to make the library easier to use, so this is good feedback, but here are my thoughts: I don't necessarily think locking is more sensitive now than it was before, you can't lock in read callbacks in the simple node manager, but apart from that, the address space in the simple node manager is less shared than the global address space would have been in the old SDK. When I write code for the SDK itself, I typically try to follow a few core rules:
As for removed functions. You're right that only the basics are left. When it comes to browsing, i.e. find_aggregates_of, find_hierarchical_references, you should just use Finally. I see most people are trying to use the You may want to look at the core node manager, which is a custom InMemoryNodeManager. You'll note that it isn't actually that complex. There's some code you need to write to deal with monitored items, and you need to implement If I were you, I'd probably not use the It's on my TODO somewhere to really implement a proper example of this type of behavior, but it's not been top priority. |
Beta Was this translation helpful? Give feedback.
-
DeadlocksThe tracing_mutex crate has been very helpful in debugging the locks Roughly speaking, this kind of usage was tripping me up Deadlocking Examplefn process_things(val: Arc<T>) {
let a = val.read();
let b = do_something(a.property.clone());
let a2 = val.read();
let c = do_something_else(a2.property.clone());
}
fn do_something(val: T){
println!("{}", val);
}
fn do_something_else(val: T){
println!("{}", val);
}Working Examplefn process_things(val: Arc<T>) {
let a_property = {
let property = val.read();
property.clone()
};
let b = do_something(a_property);
let a2_property = {
let property = val.read();
property.clone()
}
let c = do_something_else(a2_property);
}
// same aux functions as beforeThings seem to get hairy if I'm not extra careful with Type GenerationI added Code for However, |
Beta Was this translation helpful? Give feedback.
-
|
(First, notably, your example won't deadlock, you can have multiple read locks at the same time, but I get your point). That kind of issues I don't think there's anything we can really do to prevent. Object types are something very different from data types, and we don't currently generate anything for them. The way they are generated in object oriented languages is a very object-soup kind of manner that is fundamentally incompatible with Rust, and while I've had some thoughts for how we might model them, nothing has really stood out as an obviously correct choice. |
Beta Was this translation helpful? Give feedback.
-
|
I had some time, so I wrote up a simple example of implementing node managers by hand, which I think we really need, see #92 |
Beta Was this translation helpful? Give feedback.
-
|
It might also help me to see that panic with |
Beta Was this translation helpful? Give feedback.
-
|
Correct, EUROMAP83 appears to exhibit the same issue
NodeManager usage in ServerBuilder (Rust)let builder = ServerBuilder::from_config(server_config.clone());
let (server, handle) = builder
.with_node_manager(simple_node_manager_imports(
vec![
// Box::new(opcua::core_namespace::CoreNamespace),
Box::new(EUROMAP83),
],
"EUROMAP83",
))
.with_type_loader(Arc::new(
euromap83::GeneratedTypeLoader,
))
.build()
.expect("Failed to build server");
codegen.yml |
Beta Was this translation helpful? Give feedback.
-
|
This is a bug. For some reason the namespace is added incorrectly to the namespace mapper during import. I'll figure it out and make a fix. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Ah, no, I get it. This is a weakness in the codegen that I will fix, but you can work around it. The namespaces in your You also need to at some point register the For now, I got it to work with but I think formally we should avoid doing it this way. To illustrate your issue, when I want to see if I can remove the requirement for those two fields entirely. |
Beta Was this translation helpful? Give feedback.
-
|
Give #93 a try? |
Beta Was this translation helpful? Give feedback.
-
Node Metadata Lookups@einarmo I am much much closer now, thank you for the help so far Currently, I believe complex object tree creation is mostly working, but am struggling with setting property values, etc. Before, I was using With each address space now bound to a separate node manager (if I understand correctly) I cannot simply call i.e. Getting the data type of a property (String, Namespace 0) of a node in my custom namespace (not Namespace 0) I definitely expect to properly fix things at some point If "utilizing the newly added node managers" makes the most sense, for example, then that's fine |
Beta Was this translation helpful? Give feedback.
-
|
So after a few days of head-desking, I made some notable observations. I initially architected the application around numeric Node IDs Additionally, I was doing a decent amount of introspection on the address space after it was populated. Realistically, though, both of these details together introduced a much higher complexity than is needed. The more logic I move to the backing store (vs checking values in the address space), the better I think another layer of complexity was that I was working off whatever I could generate before. Anyway, long story short, nuking the cruft and stubbing in a simpler "create" and "update if exist" flow have seemed to work okay so far With this "lazy/simple" (to start) approach in mind, I think one of the only major remaining items might be IIUC, I can probably just stub these into the set variable calls or similar |
Beta Was this translation helpful? Give feedback.
-
|
That's often a good idea. In fact we have a utility in the server SDK, We even use this in the diagnostics node manager. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey @einarmo
Here is the brain vomit I mentioned earlier re issues I've experienced during migration
Sorry in advance 🤪
Overview
I have an application that currently utilizes
locka99/opcuaI am currently doing a lot of funky stuff in the library in order to try and work around the lack of easy ways to instantiate, populate, update more complex types
Related issue in original repository: locka99/opcua#310
It seems like
async-opcuahas better support for custom types, etc.But I'm so deep in the weeds re workarounds (for
locka99/opcua) that it is difficult to see what makes the most sense from my perspectiveIn making another attempt at something of a migration this last week, I have decided to record some of my most significant observations
AddressSpaceLockingI was previously passing around ... I think
Arc<RwLock<AddressSpace>>references and making changes as neededIf I understand correctly, address space locking is much stricter now, and must be done more deliberately
I tried swapping out most of the raw
AddressSpacereferences withNodeManagerreferences, and derefing as late as possibleBut that alone has not completely eliminated the deadlocks I am seeing so far
Removed functions
As part of the migration/rewrite of
locka99/opcua->FreeOpcUa/async-opcua, a number of functions have been removedThe removed functions that I can identity as "most used" within my existing codebase were previously located within the
address_spacemoduleLest I get distracted by trying to find every example...
A few notable functions that were removed from the public API:
find_aggregates_offind_hierarchical_referencesfind_variablefind_variable_mutfind_variable_mut_by_refget_variable_valueset_variable_valueI was using a number of these functions to facilitate "haphazard address space management" (as far as I understand it)
"Very manual node instantiation, reads, and updates"
This extends to node trees as well, i.e. children of the nodes being updated
Not about to ask for the reintroduction of any of these functions, as I have an idea of why they were removed
i.e. macro-dependent, overlap in functionality with existing functions, etc.
I think I managed to mostly stub things out enough to test things for the moment, anyway
Overall Application Lifecycle
The general workflow of my application currently looks something like this
The "Backing store -> OPCUA Address Space" phase is currently the most convoluted
I'm hoping it's the area that can see the most improvement
Or perhaps removed entirely, outside of idiomatic (i.e. proper) use of the provided Node Managers, etc.
In the deadlock scenario mentioned earlier in this post, I was using
SimpleNodeManager, but I'm not sure if it make sense to use in a situation where things are locked and unlocked all over the placeIf I understand correctly, the introduction of
NodeManagers is, broadly speaking, intended to help with facets such as this in terms of OPCUA server development.Whether any of the existing "simple" types of
NodeManagers available in the library can help in my particular case, I do not knowWhat Next?
I tried taking a look through the docs and available
NodeManagers, etc.But I figure it's probably best to stop digging/tinkering for a moment and provide the context around my current circumstances
Especially given how hacky the entire application lifecycle feels at the moment with my "workarounds"
For the moment, I'm seeing if I can determine the source of my deadlocks, how practical it might be to "migrate with workarounds"
I figured it's optimal that I try that angle myself to start, and let this post serve as a source for feedback on alternative approaches.
I do plan on opening more issues as needed, but these observations and additional context surrounding my use case felt more appropriate to publish as part of a new discussion, and then I can go from there if there are i.e. features I wan't to see added to the library.
Thanks again for taking the time to read all my ramblings
Beta Was this translation helpful? Give feedback.
All reactions