Page 1 of 1

Origin of Bad_SequenceNumberUnknown log outputs

Posted: 21 Jul 2022, 14:39
by gbecker
Dear all,

working with the Java OPC UA SDK, I sometimes see log messages like the ones below while running an OPC UA client with monitored items pointing to another OPC UA server. I would like to understand more about why we are seeing these and whether we should do something about them.

[INFO ] 2022-07-21 15:32:03.230 [OPC-UA-Stack-Blocking-Work-Executor-5] Subscription - Acknowledge on Subscription 1: 154 - Bad_SequenceNumberUnknown
[INFO ] 2022-07-21 15:32:03.231 [OPC-UA-Stack-Blocking-Work-Executor-3] Subscription - Acknowledge on Subscription 1: 154 - Bad_SequenceNumberUnknown
[INFO ] 2022-07-21 15:32:03.231 [OPC-UA-Stack-Blocking-Work-Executor-3] Subscription - Acknowledge on Subscription 1: 155 - Bad_SequenceNumberUnknown

I would appreciate any assistance you might be able to give to identify the root cause.

Thanks, Gerald

Re: Origin of Bad_SequenceNumberUnknown log outputs

Posted: 28 Sep 2022, 09:18
by Support Team
Hi,

the concept of the subscription mechanizm is to monitor the data of interest "on change". To do so the client sends a "token" to the server (PublishRequest) and the server answers (when detecting a data change) by sending the values (PublishResponse). Each response has a sequence number incrementing. When sending the next "token", the client acknowledges the receipt of the previous sequence number within this new PublishRequest. With this very compact mechanizm we get an effective flow control in OPC UA and we can survive network/transmission interruption without loosing any data. The client can detect if data was lost (missing sequence number) and the server can detect if client has received all (keep data until acked). The client can all "Republish" when detecting missing data.

All these details are handled by the SDK internally. The application just gets informed if something goes wrong.

In your case it seems that the client trys to acknowledge some sequence that a) does not exist yet, or b) does not exist anymore (was already acknowledged previously), or c) the server internaly mixed up the incrementing. Your best choice to analyse is Wireshark.