Some questions about callbacks in the C++ client SDK

[edoenges]

I have some basic questions about using callbacks with the C++ client SDK (version 1.3.2):

If I disconnect a UaSession object, can I assume that none of the associated callbacks will be called after disconnect() returns ?
What happens if a callback is in progress during the disconnect - will the disconnect() method wait until the callback function is finished ?
What happens if the disconnect() fails - can I still get callbacks in that case ?
If I set a UaSubscription's publishing mode to false, can I assume that I won't be getting any dataChange or newEvent callbacks after setPublishingMode() returns ? If yes, will setPublishingMode wait until any pending dataChange/newEvent callbacks have finished ?
If I delete the subscription, can I assume that I won't be getting any of its callbacks after deleteSubscription() returns ?

[Support Team]

Hi,

If I disconnect a UaSession object, can I assume that none of the associated callbacks will be called after disconnect() returns ?
What happens if a callback is in progress during the disconnect - will the disconnect() method wait until the callback function is finished ?

V1.3.2 -> The client application is responsible for keeping track of outstanding callbacks. They may arrive after disconnect() is finished e.g. readComplete().
V1.4 -> The SDK keeps track of all outstanding async transactions and returns disconnect() after all callbacks are finished.

What happens if the disconnect() fails - can I still get callbacks in that case ?

-> Disconnect will be finished and status will change to disconnected and a callback with disconnect state will be fired even if one of the disconnect steps fails. The only case where this is not true is if the client is already disconnected.

If I set a UaSubscription's publishing mode to false, can I assume that I won't be getting any dataChange or newEvent callbacks after setPublishingMode() returns ? If yes, will setPublishingMode wait until any pending dataChange/newEvent callbacks have finished ?

-> Any data or event delivery that is on its way to the client will be delivered even changing publishing mode is already finished.

If I delete the subscription, can I assume that I won't be getting any of its callbacks after deleteSubscription() returns ?

V1.3.2 -> The client application is responsible for keeping track of outstanding callbacks. They may arrive after deleteSubscription() is finished e.g. createMonitoredItemsComplete().
V1.4 -> The SDK keeps track of all outstanding async transactions and returns deleteSubscription() after all callbacks are finished.
For both versions, no dataChange/newEvent callbacks will be delivered after deleteSubscription() returns.

Best Regards,
Unified Automation Support Team

[edoenges]

V1.3.2 -> The client application is responsible for keeping track of outstanding callbacks. They may arrive after disconnect() is finished e.g. readComplete().

V1.3.2 -> The client application is responsible for keeping track of outstanding callbacks. They may arrive after deleteSubscription() is finished e.g. createMonitoredItemsComplete().
For both versions, no dataChange/newEvent callbacks will be delivered after deleteSubscription() returns.

Thank you for your answers. So basically, with SDK 1.3.2 I have to keep track of which callbacks I'm expecting and wait until I have received them before I can delete the callback object. If I do not use any of the asynchronous methods (i.e. beginXXX), the only UaSession callback I have to worry about is connectionStatusChanged, while with UaSubscriptions I need to keep track of subscriptionStatusChanged and keep in mind that I must be able to handle dataChange/newEvent callbacks until after deleteSubscription() returns. What about keepAlive - can I get one of those after deleteSubscription ?

[Support Team]

KeepAlive is like dataChange/newEvent.

In V1.3.2 there is a very small time window where a dataChange / newEvent is already processed during deleteSubscription(). This already processed callback may arrive in the application after deleteSubscription() returns. This can not happen with V1.4

Best Regards
Support Team