Hi,

It is complicated. It will take longer if you have a lot of instances, but it should not take _that_ long. Some version 4.x before 4.3.0 might have taken a long time, like 10s of minutes, but 4.3.0 and later should be faster at least). And I probably need a separate explantion for this, since it sort of might be a bug.

In general the connection typically takes few seconds, but there are some edge-cases. If the server is running on a very low-powered CPU there might be addtional slowdowns, but connecting to them usually takes 10s of seconds usually anyway. What kind of hardware the server is running on?

Basically with defaults the (quite new releases of) 4.x will read all types on connect. In the case of our SDK-made server, that includes the inverse HasTypeDefinition References from the types. Though, in general it should not be _that_ big of an impact, since our default OperationLimits is to pack 10000 in one Browse result, so it should be like 1-2 more ServiceRequests more.

Can you check the logs for debug level string “Number of ServiceRequests” and list the number of Browse, BrowseNext and Read those indicate (there is multiple lines)?

Uh oh. It is also possible that it is not this, but is worth of testing. It is also possible that there is an error in your model, and if this work it could then mask the issue.

Could you try calling UaClient.getAddressSpace().getCache().setMaxQueueLength(int) to some big number, to like e.g. 100000 and/or setNodeMaxAgeInMillis(long milliseconds) to e.g. 10000 or 100000.

The cache is by default 5000 nodes, but any type node is not counted for that, as they are cached permanently.

However, since we sort of are resolving all nodes related to the TypeDictionary (plus all other type nodes as well, since well it might be even faster to do it like that, but depends, and needs an explanation that might take a half a day to write). However, the encoding nodes are not type nodes, thus it is possible that we lose them from the cache and thus we are re-reading it from the server. Though in general I would not expect that to give such large impact.

I guess the easiest would be if you can create a standalone example with sampleconsoleserver and sampleconsoleclient (though that will probably be fine just as-is) that can reproduce this and send your model to us, if possible.

Also linking an other forum chain: https://forum.prosysopc.com/forum/opc-ua-java-sdk/source-code-does-not-match-the-bytecode/, since that is partially the same thing at least and I did write some explanations to that why we do this. It probably could be still a lot better, sorry.