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.
I believe the issue is a thread related issue rather than a ConfD issue.
$ make all start
$ make hardware_down
Using the confd_cmd tool to trigger the subscriber(s):
$ confd_cmd -dd -c "trigger"
TRACE Connected (cdb) to ConfD
TRACE CDB_TRIGGER_SUBS DEBUG Data provider returned CONFD_ERRCODE_RESOURCE_DENIED - resource denied: HARDWARE IS NOT CONFIGURABLE
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
@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