Cdb_trigger_subscriptions() blocks forever when configuration is rejected

My client is a two-phase subscriber and during startup is starts a separate thread to call thread_cdb_trigger_subscriptions(). Everything works ok except when my program rejects the configuration changes during the CDB_SUB_PREPARE phase. If I call cdb_sub_abort_trans() instead of cdb_sync_subscription_socket(), then thread_cdb_trigger_subscriptions() will keep blocked ad infinitum. I’m using ConfD 6.4. Is this the expected behavior?

I know that changes that are already stored in CDB can’t be rejected anymore, that makes no sense. I’ll change my application to do something different when it can’t apply the startup configuration. However I find this blocking behavior of thread_cdb_trigger_subscriptions() to be problematic nonetheless.

Regards,
Renato.

Hi,

I believe the issue is a thread related issue rather than a ConfD issue.

Example:

$ pwd
/Users/tailf/confd-6.4/examples.confd/cdb_subscription/twophase
$ make all start
...
$ make hardware_down

Using the confd_cmd tool to trigger the subscriber(s):

$  confd_cmd -dd -c "trigger"
trigger
TRACE Connected (cdb) to ConfD
TRACE CDB_TRIGGER_SUBS DEBUG Data provider returned CONFD_ERRCODE_RESOURCE_DENIED - resource denied: HARDWARE IS NOT CONFIGURABLE
 --> CONFD_ERR
FAILED: common_trigger_subscriptions(cs, NULL, 0), Error: Data provider returned CONFD_ERRCODE_RESOURCE_DENIED (37): resource denied: HARDWARE IS NOT CONFIGURABLE, in function do_cdb_trigger_subscriptions, line 1232

Subscriber output:

recv notification PREPARE flags=LAST subids=6 

TYPE=CDB_SUB_PREPARE
send abort

@cohult You’re right, sorry for the false alarme. I did some modifications in my program this last week and now I can’t reproduce this problem anymore, so certainly it was a problem in my code. Sorry for taking your time :confused: