How to recover from lost CDB subscription notifications?

CDB and CDB API
1

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.

2

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?

3

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.

4

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?

5

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.

6

Thank you, I’ll try this way.