What happens to notification context when ConfD exits or aborts

Core Engine and APIs
1

The ConfD user guide says an application should use the confd_register_notification_stream() API to register with ConfD for notification streams and that the notification context (struct) is filled in by ConfD when performing this registration.

Could you help me understand what happens when ConfD aborts or gracefully exits? the application really has a pointer to this notification context structure and it should not call confd_notification_send() with that notification context struct as it could be bogus. How do we check if the registration is “active” prior to calling confd_notification_send() with that structure? There does not seem to be an API to check if there is an active registration with ConfD for a notification stream.

2

Nothing.:slight_smile: Generally speaking, it is up to the application to detect that the connection to ConfD is closed (for whatever reason), and do one of

  1. Terminate (as shown in the example for confd_fd_ready() in the confd_lib_dp(3) man page), with the assumption that it will be started again by some kind of process manager.

  2. Close all sockets, if using the DP API call confd_release_daemon(), and redo all initialization towards ConfD “from scratch”.

A demonstration of alternative 2 can be found in the intro/9-c_threads example in the release.

Detecting the connection close is typically straightforward for a DP daemon that implements callbacks, since it will have the control and worker sockets in its poll() set, poll() will report a socket as “ready” when the connection is closed, and the subsequent call of confd_fd_ready() will return CONFD_EOF.

Of course a daemon that only does notification sending, and relies on ConfD’s builtin replay store, doesn’t have any callbacks - but it can use the same technique to detect connection close: use poll() for e.g. the control socket, and since no callbacks will be invoked, poll() reporting the socket as “ready” implies that the connection has been closed. The notifier_builtin_replay_store.c program in the netconf_notifications example uses this technique - it actually calls confd_fd_ready(), which is also fine and perhaps clearer, even though the only possible outcome is that it returns CONFD_EOF.

Per above, nothing happens “automatically” with the notification context as such when the connection is closed, but of course it holds the socket file descriptor provided via the confd_register_notification_stream() call, and this socket can no longer be used for sending notifications to ConfD. If it is attempted anyway, confd_notification_send() will fail with CONFD_EOF - though the OS socket API doesn’t report the problem until (at least) the second attempt to write to the socket, and thus confd_notification_send() will also not fail until the second call after the connection close.

In any case, this is an alternative way to detect the connection close if the control socket isn’t poll()ed. Note though that all notification contexts for a daemon are released by a call to confd_release_daemon() - i.e. after that call, all pointers to notifications contexts are invalid, and a call of confd_notification_send() with such a pointer is likely to result in a crash.

The registration will be “active” as long as the connection isn’t closed, i.e. provided that the connection close is detected and handled per above, such a check isn’t really necessary. To be “super-safe”, the confd_notification_flush() function could perhaps be used, but it defeats the purpose of the notification sending being asynchronous from application to ConfD - i.e. the round-trips will limit the rate at which notifications can be sent.