Log In
Register
Topic RSS
16:44, EET
December 3, 2025
Offline
Hello,
quick presentation of our setup : we have 2 devices hosting one OPC-UA server each. In order to implement the desired features of our product, each server access nodes in its own AddressSpace aswell as nodes in the AddressSpace of the other device.
Some actions in our system have cascading read/writes effects – one modification to a node can trigger a new fetching of part of the AddressSpace, and concurrent reads happen fairly often.
We run into an issue that seems to be related to reading of nodes. After some “random” amount of requests, the application becomes unresponsive. After thorough debugging, the issue seems to be a deadlock when using uaClient.getAddressSpace.getNode(). Specifically, we presume the issue comes from the NodeCache, even though that may or may not be true. We’ve tried “partially disabling it” using following methods :
uaClient.getAddressSpace().getCache().setNodeMaxAgeInMillis(1);
and uaClient.getAddressSpace().getCache().setMaxQueueLength(0);
This didn’t fix the issue.
Reading the changelog of version 4.10.6 seems to have fixed a similar issue : https://downloads.prosysopc.co…..Notes.html
(Fixed: A race-condition in AddressSpace.getNode(…) causing a deadlock, if multiple threads tried to get the same node concurrently.)
However, we’re using version 5.3.0 of the Prosys SDK, so that fix should already be included.
Is there any known issue regarding these kinds of deadlocks ? Is there an easy way to completely disable the NodeCache to see if it’s related ?
Thank you!
9:28, EET
April 3, 2012
Offline
Hi,
Could it be possible to get a thread dump (if yes, please send to jsdk-support@prosysopc.com)? Or if not, please analyze it and find one or more threads in BLOCKED state and then please post (or send) stacktraces of those threads. That would show on what they are waiting.
Regarding the NodeCache, in the past there were issues. Basically there is a node-level lock, since fetching one is not atomic and needs multiple requests; the 4.10.6 fix was related to an error that it was possible to get multiple locks for the same node.
In short it is not possible to disable NodeCache. Note that types are permanently cached regardless of the node age as they are assumed immutable for the duration of the connection (otherwise we would need to constantly fetch metadata).
10:42, EET
December 3, 2025
Offline
Thank you for your quick reply ! I just sent a full thread dump to the mail you provided. Just in case, here is the upper part of a thread dump that is blocked :
“http-nio-9070-exec-1” #144 [26508] daemon prio=5 os_prio=0 cpu=343.75ms elapsed=154.18s tid=0x000002943ce02a80 nid=26508 waiting for monitor entry [0x000000cbb49fc000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.prosysopc.ua.client.AddressSpace.getNode(SourceFile:1042)
– waiting to lock (a java.lang.Object)
Another interesting part :
“MessageBroker-1”:
at com.prosysopc.ua.client.NodeCache.createNode(SourceFile:320)
– waiting to lock (a com.prosysopc.ua.client.NodeCache)
at com.prosysopc.ua.client.AddressSpace.getNode(SourceFile:1080)
– locked (a java.lang.Object)
For reference, our use case is the following :
HTTP call from a front-end to a back-end, which then retrieves information in the AddressSpace and returns it to the caller.
14:31, EET
April 3, 2012
Offline
Ok, we did find one possible cause. Just to be sure, assuming it is possible to answer:
Do you create dynamically new types in the server (after connecting)?
Or
Have you changed the defaults where UaClient does read all types of the server on .connect (any client.setInitTypeDictionaryXXX(false) calls)?
IF ‘no’ for both, then it is possible there are multiple causes (but we try to work on the one we found at least for now).
When creating the nodes in the client side (same for server, but ignoring that part here) the SDK must know the “most generated subtype” for the HasTypeDefinition Reference target of the node, so that it knows which UaNode implementation to choose (and to allow generated code to work on non-generated subtypes). SDK already has generated the core OPC UA information model, and all types directly or indirectly subtype them (so it will always find them, eventually).
Now then, if there is no direct match for HasTypeDefinition, we loop supertypes (of the reference target). IF another thread managed to be .getNode:ing any of these types (and assuming they weren’t already in the cache from UaClient.connect) at the same time, seems there is possibility of a deadlock (skipping details).
Running Codegen on any custom types (assuming they are in a NodeSet XML file) could also work as a workaround, assuming they types are static. Or if ‘yes’ on the UaClient.connect thing then changing it back to read all types should also workaround it (assuming no types are added after that).
Anyway, we will try to fix this and send a beta link by email once done
16:39, EET
December 3, 2025
Offline
We do indeed create various types that are specific to our domain. But we never call client.setInitTypeDictionary type methods. So I guess you’re on the right track regarding the analysis !
Looking forward for the beta version, thanks!
1 Guest(s)
