How to recover from lost CDB subscription notifications?

One way to insure that your CDB subscriber application hasn’t lost any CDB subscription notifications upon a reconnect is to keep track of the very last transaction ID from CDB. You can do that by using the cdb_get_txid() API call either inside or outside of a CDB session. In order to insure that you have indeed saved the latest txid in persistent storage, you will want to have a lowest priority subscription that is subscribed to the entire data model at the root with “/”. This will ensure that all notifications has been delivered and processed before you invoke the cdb_get_txid() call to save the most current transaction id in persistent storage.

cdb_get_replay_txids() allows you to find out the last transaction, txid[0], and the one before that, txid[1]. If your stored txid prior to the disconnect matches txid[1], you can invoke cdb_replay_subscriptions() to replay the lost CDB subscription notification. Please note that both of these APIs need to be invoked inside of a CDB session. In addition, the cdb_replay_subscriptions() call is blocking and needs to be invoked from a process (or thread) separate from the CDB subscriber. The replay functionality is only available if it has been enabled in confd.conf with /confdConfig/cdb/subscriptionReplay/enabled set to true.

If your stored txid is older than txid[1], you will need to either re-read everything from CDB or invoke cdb_trigger_subscriptions() to cause all of past CDB subscriptions to be triggered.

As an alternative, the cdb_mandatory_subscriber() call can be used while setting up the CDB subscriber in order to insure that all transactions don’t go through unless your CDB subscriber application is running.

This question is what I wanna ask.

But the guide says that absence of one or more mandatory subscribers will result in abort of all transactions, so if I have more than one subscriber, no matter which one is disconnected from confd, all the others are failed to configure.Is there any way to avoid this problem?

This only happens if you register your cdb subscribers as mandatory subscribers. If you register them as regular (or non-mandatory) subscribers without invoking the cdb_mandatory_subscriber( ) call, you can continue to configure CDB through any northbound interfaces even when all of subscribers have aborted.

Thanks wai.
But I wanna all the subscribers to be mandatory subscribes , so that I won’t lost any configuration of each subscriber, and meanwhile if one of the subscribers crashed, I wish others could work normally. How to make it?

One other suggestion I have is to have a single mandatory subscriber that tracks the latest transaction ids for each of your other non-mandatory subscribers. Perhaps store those data using a hidden data model that are accessible to all of your cdb subscribers. The non-mandatory cdb subscribers will also persist its copy of the latest transaction id. Upon restart of your non-mandatory subscriber, it can compare its own copy with the one retrieved from CDB (the hidden data model) and determine if it is necessary to re-read the configuration data.

Thank you, I’ll try this way.