### Description
_**Sipwise** hat on_
We noticed that pkg memory was getting exhausted and we found out that pv_cache_add() was the origin of the allocations. We are using ``$xavp(user_<UUID>)`` variables that, for sure, are kind of dynamic.
There is a pv_cache_drop() that tries to remove ``$sht()`` occurrences when the cache is about to be filled but in our case that's not helping.
#### Log Messages
``` WARNING: ROUTE_SET_CALLEE_DIALOG_TOTAL <core> [core/pvapi.c:340]: pv_cache_add(): pv cache limit is going to be exceeded - pkg memory may get filled with pv declarations WARNING: dialog:failed <core> [core/pvapi.c:340]: pv_cache_add(): pv cache limit is going to be exceeded - pkg memory may get filled with pv declarations ```
### Possible Solutions
Possible solutions that came on the top of my head:
- add a datetime member to struct _pv_cache so we can keep the last time it was accessed and search for the oldest and remove them in pv_cache_drop() - add pv module parameter to define a magic prefix, for instance '__' that will mark those vars as "temporal" should remove it from cache when needed. - add pv module parameter to control what types of variables will be added to cache
Any thoughts about this?
How do you use the `$xavp(...)`? Do you need to work with them using the kamailio-PV-style name? Otherwise it might be better to use the dedicated functions exported to kemi from pv module:
- https://www.kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/module...
Then, yes, we can also think of ways to make the pv cache more flexible for cleaning, ...
I'm going to try first the keeping last_access solution I think would be a more generic solution
It might be a bit tricky to really make it generic, because some variables keep pointer to shared memory, definitely is not going to work for `$shv(...)` to be (re-)initialized after forking. So if a shv is used not very often and destroyed, then it becomes unusable for ever, (re-)initialisation will not make it properly visible to all processes. Then I am not sure that every PV does a full clean on destroy of their internal structure, so it can still leak. That's also a reason now is done for sht, because its destroy was reviewed to be clean.
So, likely you have to combine with a list of variable types that are ok for last-access-based destroy and (re-)initialise.
This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
Closed #3440 as not planned.