Ankit Gupta

> Okay, can you tell me more about the exact scenario? Is the application calling the `sr_oper_get_subscribe()` multi-threaded or are there simply more subscriptions being done simultaneously in several threads/applications?...

> Okay, then it could be another thing, are the callbacks called immediately after being subscribed? Meaning are the operational data the subscriptions provide immediately retrieved? Hi, no. We are...

I have printed all the APIs as well, and if you see you won't find any other API interfering with sysrepo. Even thread IDs I have tried printing, all are...

> > I will also try one more thing, to add additional logs inside sysrepo API to check what could be the problem. > > Try that or something else...

Hi @michalvasko Sorry to bother you again, we are kind of stuck with this version upgrade due to the mentioned reason. Did you got any chance to have a look...

Hi @michalvasko Earlier when I mentioned only subscription is happening, it was from the application's point of view. But yes of course they are Netconf get calls happening while operational...

> > And we added a retry mechanism up to 3 times in case we observe TIMEOUT error, however it still fails. > > I see, then the problem seems...

> > ... try to collectively get it resolved, if that works for you. > > This is what I am trying to avoid because it is the most inefficient...

Hi @michalvasko After quite some tests, Though it is a very dirty way but I have prepared some example which once ran will reproduce similar problem of timeout for operational...

Hi @michalvasko, One potential place, I have observed which can be problematic, would like to get your opinion. Can misuse/missed sr_release_ctxt for sr_acquire_context() causes the below error? 2023-12-04 06:52:31.567027 err...