I have a model with nested list. I have implemented the get_next_object based on the design you had suggested in another topic.
As the list has 433 entries i have designed the get_next_object function to return 100 objects at a time. I have also made sure that proper next values are also sent with confd_data_reply_next_object_arrays function. I am noticing that after the first set of 100 objects are sent back to confd with proper next value , the very next call back to get_next_object had the next value as 32 (its random). I was expecting it to be 100. Please note as i have a list of 433 elements , so with existing design i am expecting callbacks atleast 5 times , each call carrying back 100 objects to confd. But the actual execution doesn’t match with my understanding as sometimes the callback has next value as 3 more than the previous next value. The value of next is not in multiples of 100 as expected.
Overall output in both CLI and netconf shows 433 entries. So no data is lost. But the number of confd calls are high.
Along with the logic of sending back 100 objects , do i need to set some more logic?
It is usually hard to guess what’s is happening without seeing the application code and some parameters but I can say ConfD does not guarantee how many times it would perform calls and which next value it would use. That being said, you would, of course, like to optimise the data transfer and networking by fine tuning your application.
Could you tell me what value do you pass for timeout_millisecs in confd_data_reply_next_object_arrays function and if it is 0 what is configured for /confdConfig/capi/objectCacheTimeout parameter in confd.conf. Also you told that the model has a nested list structure. What is the depth and how large are the sizes of nested lists? Are there any dependencies in-between any of these lists towards each other or even to it self, like leafref types as list items?
it’s not impossible i guess, but usually “next” values for callbacks are rather correctly set to either -1 or exact values provided back by client app in previous callback calls… Can you double check e.g. for casting errors, un-initialized mem blocks etc. e.g. using valgrind tool (oss @ www.valgrind.org) for the data provider implementation codebase?