Data not returned by ReadRawModified

[mdbowden]

We are doing scalability testing for our OPC UA Server
When we submit a ReadRawModifed request from our own UA test client a large amount of data (13 tags, of 1 second data, for 7 days) we get the following error:

BadResponseTooLarge

We are looping round multiple calls to ReadRawModified and believe we are setting the continuation points correctly for each tag for the subsequent calls.

If we reduce this to 12, we get the data back. Assuming the error is returned from the SDK in response to a large query, have you any idea as to what is the cause and possible solution? We are thinking there may be a setting in the SDK / ServerConfig.xml that we can change to tune this.

Our continuation points are returning with 49998 bytes, which we do not think is something we are explicitly configuring.
(I had an earlier query involving this magic number, and it turns out our harness was not handling continuation points correctly)

We are using v1.7.9 of the C++ SDK.

Thanks,

Matthew Bowden

[mdbowden]

We upgraded our client to 64-bit an added logging OPCUA_TRACE_OUTPUT_LEVEL_INFO as shown below, reading 15 1sec tags over 1 day.

|00005A24| 2023-10-30T13:43:53.438Z OpcUa_Channel_ResponseAvailable: ReadResponse
|00005A24| 2023-10-30T13:43:56.072Z OpcUa_TcpConnection_ProcessResponse: Message aborted after 255 chunks!
|00005A24| 2023-10-30T13:43:56.072Z OpcUa_SecureConnection_AbortResponse: SID 3216524358, TID 1, Connection Status 0x00000000
|00005A24| 2023-10-30T13:43:56.072Z OpcUa_SecureConnection_AbortResponse: Abort Reason Status 0x80B90000
|00005A24| 2023-10-30T13:43:56.072Z [W] OpcUa_Channel_ResponseAvailable: Request failed! (0x80B90000)

]We also logged:
nMaxMessageSize:16777216
nMaxArrayLength:65536
nMaxByteStringLength:16646145
nMaxStringLength:16646145

Because it referred to the magic number 255 I also had a guess and tried with modified init settings:
UaPlatformLayer::changeTransportSettings(OpcUa_True, -1, -1, -1, 0);
UaPlatformLayer::changeTransportSettings(OpcUa_True, -1, -1, -1, 10000);
But this made no difference.

Matthew.

[Support Team]

Hello Matthew,

the error is generated on the server side when trying to send a response that is larger than the MaxMessageSize. The solution is not increasing the MaxMessageSize or any other protocol parameters. The server needs to split the response into smaller chunks and set a continuation point.
What is the maximum number of values you return for each tag in your HistoryManager implementation in the server?
What's the DataType used for history values here?
How many values are returned in the previous responses and how many values does the server try to send in the last response (the one that fails)?