Michal Vasko

Are you maybe subscribed to the particular notification sent in the callback of `sr_module_change_subscribe()`?

It still seems to me like a normal timeout, now you mention 1000 instances of a list. Try running the server with an increased timeout (`netopeer2-server -t 100`).

Context lock is only `READ` in both cases, which can be held simultaneously.

I managed to reproduce it but completely fail to understand how it can occur, there is SUBS READ lock when checking the stop time and SUBS WRITE lock when reallocating...

There have been quite a lot of fixes implemented in *netopeer2-server* recently and I cannot reproduce this at all now. Please, use the latest `devel` branches and let me know...

I have failed to compile your code because of messy devel packages of `glib` so I gave up on that. I have tried to run ``` examples/oper_data_pull_example ietf-system /ietf-system:* ```...

Tried it with the latest code in `devel`, it worked fine. I have fixed `get` RPC not that long ago, so it should now behave much more like `get-data`.

1. The first error is the specific error, the second one is the more generic error. But they are not 2 errors, the first one is causing the second one....

Yes, you cannot handle invalid YANG data yourself, it is processed internally.

> why are we not limited to registering only one subscription for a RPC like sr_oper_get_items_subscribe ? Because you have the option for more subscribers to be notified about an...