Timeout between ocnfd and the external dataprovider

We have an external dataprovider that provides the oper data. In a high scale scenario the dataprovider is taking very long to respond back. We expected this and bumped up both /confdConfig/capi/newSessionTimeout and /confdConfig/capi/queryTimeout to 1hour by setting them to PT1H. So I expected it to timeout at exactly 1hour. But the netconf logs are showing that it is waiting for 3 hours before timing out. So I am wondering why it is waiting so much longer than what is configured? We are not concerned about the performance of the dataprovider but only concerned about the configured timeout not being used. We made sure to restart confd after the timeouts were changed.

Following are the 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

In the post above you say that you are “not concerned about data provider is taking too long to respond.”.
Although the /confdConfig/capi/queryTimeout and newSessionTimeout control the timeout for exactly that, i.e. your data provider. The error you get, “couldn’t retrieve all data from the data providers, closing session”, is due to your data provider applications not responding.

As I wrote in the original post:

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.

This will give you a better overview on what is actually going on with your data provider and will give you more details on why the timeout you observe is 3h.