Log In
Register
Forum
Topic RSS
17:58, EEST
April 20, 2020
Offline
Hello 
,
I am using Prosys Java Client SDK version 4.3.0-1075 to connect with a UA Server based on open62541. While connecting, I am getting this error. However the connection is successful.
04/20/2020 16:10:57.931 INFO com.prosysopc.ua.client.UaClient – Server doesn’t support OperationLimits nodes or gives Null values, using client defaults for OperationLimits
04/20/2020 16:11:00.092 ERROR .prosysopc.ua.stack.transport.tcp.io.TcpConnection – Decoding error for Message
com.prosysopc.ua.stack.encoding.DecodingException: Bad_EncodingLimitsExceeded (code=0x80080000, description=”MaxStringLength 65535 < 1917845504")
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.getString(SourceFile:2913)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.getQualifiedName(SourceFile:1378)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder$11.b(SourceFile:1238)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.get(SourceFile:482)
at com.prosysopc.ua.types.opcua.Serializers$ReferenceDescriptionSerializer.getEncodeable(SourceFile:1188)
at com.prosysopc.ua.StructureSerializer.getEncodeable(SourceFile:83)
at com.prosysopc.ua.stack.encoding.utils.AbstractSerializer.getEncodeable(SourceFile:155)
at com.prosysopc.ua.stack.encoding.utils.SerializerComposition.getEncodeable(SourceFile:109)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.getEncodeable(SourceFile:839)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder$16.b(SourceFile:1269)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.get(SourceFile:498)
at com.prosysopc.ua.types.opcua.Serializers$BrowseResultSerializer.getEncodeable(SourceFile:1291)
at com.prosysopc.ua.StructureSerializer.getEncodeable(SourceFile:83)
at com.prosysopc.ua.stack.encoding.utils.AbstractSerializer.getEncodeable(SourceFile:155)
at com.prosysopc.ua.stack.encoding.utils.SerializerComposition.getEncodeable(SourceFile:109)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.getEncodeable(SourceFile:839)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder$16.b(SourceFile:1269)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.get(SourceFile:498)
at com.prosysopc.ua.types.opcua.Serializers$BrowseResponseSerializer.getEncodeable(SourceFile:1821)
at com.prosysopc.ua.StructureSerializer.getEncodeable(SourceFile:83)
at com.prosysopc.ua.stack.encoding.utils.AbstractSerializer.getEncodeable(SourceFile:155)
at com.prosysopc.ua.stack.encoding.utils.SerializerComposition.getEncodeable(SourceFile:109)
at com.prosysopc.ua.stack.encoding.binary.BinaryDecoder.getMessage(SourceFile:1306)
at com.prosysopc.ua.stack.transport.tcp.io.TcpConnection$b$1.run(SourceFile:497)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
04/20/2020 16:11:32.839 WARN com.prosysopc.ua.client.UaClient – Could not init TypeDictionary, decoding custom Structures might not work
com.prosysopc.ua.typedictionary.TypeDictionaryException: Cannot init typedictionaries
at com.prosysopc.ua.typedictionary.TypeDictionary.init(SourceFile:415)
at com.prosysopc.ua.client.UaClient.connect(SourceFile:10072)
at de.siemens.sd.it.pd.rd.appl.opcua.console.RoboDriveClient.connect(RoboDriveClient.java:364)
at de.siemens.sd.it.pd.rd.appl.opcua.console.RoboDriveClient.mainMenu(RoboDriveClient.java:700)
at de.siemens.sd.it.pd.rd.appl.opcua.console.RoboDriveClient.main(RoboDriveClient.java:60)
Caused by: com.prosysopc.ua.client.AddressSpaceException: Could not resolve all required Properties witin getNodes
at com.prosysopc.ua.client.AddressSpace.a(SourceFile:2449)
at com.prosysopc.ua.client.InternalAddressSpaceAccessHelper.internalGetNodesWithNodeIdsAndPreBrowseData(SourceFile:65)
at com.prosysopc.ua.typedictionary.TypeDictionary.atX(SourceFile:1221)
at com.prosysopc.ua.typedictionary.TypeDictionary.init(SourceFile:392)
… 4 more
Caused by: com.prosysopc.ua.ServiceException: Bad_Timeout (code=0x800A0000, description="The operation timed out.") ServiceResult=Bad_Timeout (0x800A0000) "The operation timed out."
at com.prosysopc.ua.client.AddressSpace.browse(SourceFile:401)
at com.prosysopc.ua.client.AddressSpace.b(SourceFile:2080)
at com.prosysopc.ua.client.AddressSpace.a(SourceFile:1970)
at com.prosysopc.ua.client.AddressSpace.b(SourceFile:1932)
at com.prosysopc.ua.client.InternalAddressSpaceAccessHelper.internalBrowseWithNodeIds(SourceFile:47)
at com.prosysopc.ua.client.InternalAddressSpaceAccessHelper.internalBrowseAllDataWithNodeIds(SourceFile:35)
at com.prosysopc.ua.client.AddressSpace.a(SourceFile:2443)
… 7 more
Caused by: com.prosysopc.ua.stack.common.ServiceResultException: Bad_Timeout (code=0x800A0000, description="The operation timed out.")
at com.prosysopc.ua.stack.transport.impl.AsyncResultImpl.waitForResult(SourceFile:287)
at com.prosysopc.ua.stack.transport.tcp.io.SecureChannelTcp.serviceRequest(SourceFile:869)
at com.prosysopc.ua.stack.transport.tcp.io.SecureChannelTcp.serviceRequest(SourceFile:808)
at com.prosysopc.ua.stack.application.SessionChannel.serviceRequest(SourceFile:399)
at com.prosysopc.ua.stack.transport.ChannelService.Browse(SourceFile:205)
at com.prosysopc.ua.client.AddressSpace.browse(SourceFile:396)
… 13 more
If I set for example, client.getEndpointConfiguration().setMaxStringLength(Integer.MAX_VALUE), I will get com.prosysopc.ua.stack.encoding.DecodingException: Bad_EndOfStream (code=0x80B00000, description="Buffer underflow") instead. There errors can also be observed when running your sample clients.
My questions are:
1) Should the warning be of any concern? So far I couldn’t observe any negative behavior on my client. I can browse, call a method and subscribe to an event on the server.
2) These errors appear when I’m using Java 7 to run the client. But not with Java 8. What does the Java version have anything to do with it?
Thank you for any help,
Fahmi
14:10, EEST
April 3, 2012
Offline
Hi,
Thanks for informing us.
The short version: The server doesn’t seem to support operation limits, thus we use defaults (10000 operations within a request) that might make the messages too large for the server to encode resposes, thus timeouts. I’ll make a beta build which allows you to try a lower default limit to see if it helps. Send mail to uajava-support@prosysopc.com to get the beta version.
The long version:
0.
Based on the “04/20/2020 16:10:57.931 INFO com.prosysopc.ua.client.UaClient – Server doesn’t support OperationLimits nodes or gives Null values, using client defaults for OperationLimits” I have somewhat good idea what is going on here. I’ll have to make a small change before you can try a workaround, thus if you are interested trying with a beta version, send mail to uajava-support@prosysopc.com.
Basically the optimizations of 4.3.0 make it so that we’ll make fewer, but larger servicerequests when UaClient connects (before we did a lot of small requests, thus latency was multiplied by like 100-fold). This was mainly done for TypeDictionary, but additionally any UaNode-based interaction will benefit as a side-effect (as AddressSpace caches any types). Basically we now Browse and Read the entire type-space of the server on connect. While that sounds a bit counter-intuitive, when done bulk is quite effective and fast. The same data pretty much would be needed once you’ll interact with any UaNode, and at that point it cannot be optimized as easily. Also since we know we’ll want all, we can start by Browsing all known type identifiers from the standard model (at the same time).
If the server doesn’t provide OperationLimits, we’ll use defaults. Normally you could set a client-side defaults via UaClient.setOperationLimits(OperationLimits limits), and the actual used limits is a min(clientside, serverside) of them, however currently if reading them fails it would use OperationLimits.defaults() instead. I’ll have to change it so that it uses the ones set via that setOperationLimits (the default value for that then the OperationLimits.defaults()).
Those defaults are:
maxMonitoredItemsPerCall=10000, maxNodesPerBrowse=10000, maxNodesPerHistoryReadData=10000, maxNodesPerHistoryReadEvents=10000, maxNodesPerHistoryUpdateData=10000, maxNodesPerHistoryUpdateEvents=10000, maxNodesPerMethodCall=10000, maxNodesPerNodeManagement=10000, maxNodesPerRead=10000, maxNodesPerRegisterNodes=10000, maxNodesPerTranslateBrowsePathsToNodeIds=10000, maxNodesPerWrite=10000
So the workaround I would like you to try (IF possible) to set e.g. 1000 to the client side limits instead of the default 10000 and try again (but note that you will need the beta build for it to work like that).
1. The error means that the SDK was not able to init the TypeDictionary, this means that any decoding of unknown (not-codegenerated) custom Structures will fail (you will get an ExtensionObject instead within the DataValue instead of a DynamicStructure instance). If you are not interacting with any custom Structures, you can ignore it.
2. At least HashSet/HashMap iteration order works differently between the two Java versions. Might be something else as well, but this could make sense at least. Note that it shouldn’t like in general matter here, i.e. it doesn’t matter in which order we do Read nodes if we do Read them all. However, since the server doesn’t support operation limits, and we use the default 10000 operations per a single Read call it is possible that it is too much for the server in some cases. However if you happen to read the nodes in just right order it might be less than some allocated memory that would be used for encoding the response. However if the order is something else, it could be over the limit. If that were to happen, the iteration order would cause a difference in results. I’ll guess just in case in some future versions we should use something with deterministic iteration order (if that by itself doesn’t hurt performance) if for nothing else than to avoid a potential confusion like this.
11:17, EEST
April 20, 2020
Offline
I was waiting for a notification through e-mail if any reply comes. Yet there was already a reply more than a week 
.
Nonetheless, thank you for the detailed explanation. I think I’ve tried to set the client limit but nothing happened. But as you mentioned it, it won’t work without the beta-build. So I’ll send an email later.
I could relate your explanation regarding the effect of different Java versions as I compared the debug output of my consoles.
13:09, EEST
April 3, 2012
Offline
Sorry! It is a bit outside of my expertise, but this forum is really simple thus I’m not sure things like email-notifications are possible.
However each section does have an RSS feed that most email clients should be able to handle (e.g. for this section it is https://forum.prosysopc.com/forum/opc-ua-java-sdk/rss/). Also you can use http://www.prosysopc.com/blog/forum/rss/ to get notifications from all of them at once.
17:58, EEST
April 20, 2020
Offline
No problem . It’s just a missunderstanding with the notification.
So using the beta-version, it works now. I had to decrease the limit to 100 (to be exact maximum 386). Thank you very much for the quick support
13:34, EEST
April 3, 2012
Offline
Ok, good.
Still that is quite low limit. Where possible you could try to contact the server’s manufacturer to see if they could add the operation limits nodes (and if the limits really need to be that low). Note that different service calls might have different limits, so you could also try to experiment if e.g. the maxNodesPerRead or maxNodesPerBrowse itself could be higher. Basically the initialization uses those two.
Most Users Ever Online: 518
Currently Online:
20 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
hbrackel: 135
pramanj: 86
Francesco Zambon: 81
rocket science: 77
ibrahim: 75
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
fred: 41
Member Stats:
Guest Posters: 0
Members: 679
Moderators: 16
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1467
Posts: 6259
Newest Members:
DonaldPooma, fidelduke938316, Jan-Pfizer, DavidROunc, fen.pang@woodside.com, aytule, rashadbrownrigg, christi10l, ahamad1, Flores FrederickModerators: Jouni Aro: 1009, 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
