Maapi_get_next is timing out

In my application, maapi_get_next is timed out. TRACE MAAPI_GET_NEXT /DC-BGP-MIB:DC-BGP-MIB/bgpPeerStatusTable/bgpPeerStatusEntryDEBUG external error - application timeout. During this show operation, application returning CONFD_ERR to confd. Due to this, CONFD is sending CONFD_EOF on socket. Is there any way to distinguish error with timeout , so that, application can return delayed response , instead of Error. If there is any other solutions are available for this issue .


The issue is as you write in your data provider application that timeout and ConfD then handle your data provider failure by closing the control and worker sockets to your data provider application.

Note that if you do a MAAPI call like maapi_get_next() from a the same thread that also is the data provider to serve your maapi_get_next() you will have a deadlock. If this is what you are doing this may explain your timeout.

First a short explanation on data provider failures due to timeouts from the confd_lib_dp man page:

All the callbacks that are invoked via these sockets are subject to timeouts configured in confd.conf, see confd.conf(5). The callbacks invoked via the control socket must generate a reply back to ConfD within the time configured for /confdConfig/capi/newSessionTimeout, the callbacks invoked via a worker socket within the time configured for /confdConfig/capi/queryTimeout. If either timeout is exceeded, the daemon will be considered dead, and ConfD will disconnect it by closing the control and worker sockets.

So basically you have three options here:

  1. Make sure you are not in a deadlock situation.
  2. Increase the timeout in your confd.conf file to your worst case timeout.
  3. For just this callback, and others that may take a long time in your data provider application, call confd_data_set_timeout() with the timeout to extend the timeout to match your worst case for the current callback, i.e. in your case the data provider callback you registered with ConfD.

From the confd.conf man page:

/confdConfig/capi/queryTimeout (xs:duration) [PT120S]
Timeout for a daemon to respond to a worker socket query, see confd_lib_dp(3). If the daemon fails to respond within the given time, it will be disconnected.

From the confd_lib_dp man page:

*int confd_data_set_timeout(struct confd_trans_ctx tctx, int
A data callback should normally complete “quickly”, since e.g. the execution of a ‘show’ command in the CLI may require many data callback invocations. Thus it should be possible to set the /confdConfig/capi/queryTimeout in confd.conf (see above) such that it covers the longest possible execution time for any data callback. In some rare cases it may still be necessary for a data callback to have a longer execution time, and then this function can be used to extend (or shorten) the timeout for the current callback invocation. The timeout is given in seconds from the point in time when the function is called.

Edited my previous reply after getting help from the experts. You will not benefit from calling CONFD_DELAYED_RESPONSE to avoid the timeout. The delayed response will just allow your application to avoid hanging in the callback waiting for a reply from the data source.

Also, note that your issue might be caused by a deadlock situation where the same thread calling maapi_get_next() is also the data provider for the maapi_get_next() request.

Hi Cohult,
Thanks for the response.

i am dealing with an external data provider. I bumped up both /confdConfig/capi/newSessionTimeout and /confdConfig/capi/queryTimeout to 1 hour using by setting them to PT1H but the logs seem to show that they wait for close to three hours. Following are the confd netconf logs.
5-Sep-2017::14:49:48.255 N9K-ToR-Leaf2 confd[350]: netconf id=28 new tcp session for user “admin” from
5-Sep-2017::14:49:48.310 N9K-ToR-Leaf2 confd[350]: netconf id=28 got rpc: {urn:ietf:params:xml:ns:netconf:base:1.0}get attrs: message-id=“1”
5-Sep-2017::14:49:48.319 N9K-ToR-Leaf2 confd[350]: netconf id=28 get attrs: message-id=“1”
5-Sep-2017::14:49:48.332 N9K-ToR-Leaf2 confd[350]: netconf id=28 sending rpc-reply, attrs: message-id=“1”
5-Sep-2017::17:45:05.501 N9K-ToR-Leaf2 confd[350]: netconf id=28 couldn’t retrieve all data from the data providers, closing session

You would be better served and would help others by creating a new topic for this new question, rather than piggybacking on a year old topic.

See the ConfD developer log with log level set to ‘trace’ (ConfD side) + your application’s libconfd trace log (application side) for details on what is going on with your data provider application.

I opened a new topic. we are anyway not concerned about dataprovder taking too long to respond. We are concerned about why the configured timeout is not taking effect. I mentioned the same in the new topic I created. I will continue the discussion there.