<div dir="ltr">Thx for the reply<br>Yes<br>Internal hash table diffenentelly stores info<br>But even it case of putting timeout to 0 it still grows in synthetic tests. So looks like it will grows alsways because of deletes entries but creates new and so on and so on...<br>So means it decrases "leak" but not fully<br><br>Is there some hidden function maybe to drop hast table o some ticky to do this? (we are using oru ow algorinthm that garanties to use same node in case of transaction)</div><br><div class="gmail_quote"><div dir="ltr">ср, 2 янв. 2019 г. в 16:45, Richard Fuchs <<a href="mailto:rfuchs@sipwise.com">rfuchs@sipwise.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 02/01/2019 07.45, Yuriy Gorlichenko wrote:<br>
> Hi!<br>
> Happy new year to all!!!<br>
><br>
> Look like I am first in this year wit hthe questions in this list :-).<br>
><br>
> I'm using stateless kamailio and RTPengnine to build some kind of the <br>
> stateless cluster<br>
> I found that kamailio keeps some data  in the SHMEM in case of using <br>
> RTPengine module even if it is not a rtpengine_manage function but <br>
> offer/answer/delete<br>
><br>
> In this case if INVITE (offer) handled by 1-st kamailio in my cluster, <br>
> and BYE/CANCEL handled by second kamailio in the cluster - 1-st <br>
> kamailio (which has been used for offer) will hase kinda internal <br>
> "memory leak" (in SHMEM it never decrased)<br>
><br>
> At the rtpengine module source I found some transation dependencies <br>
> for the rtpengine_manage function but did not find for the <br>
> offer/answer/delete<br>
> I supposed these 3 functions just sending requests to the rtpnegine <br>
> with keys and not storing anything<br>
><br>
> So my question - is it possible to use RTPengine module in stateless <br>
> way to avoid internal "memory leak" because in my scenario I have big <br>
> chance never receive  BYE/CANCEL on the machine that started handle <br>
> particular call<br>
<br>
<br>
This is probably the module-internal hash table that is used to make <br>
sure that signalling relating to the same call is always sent to the <br>
same rtpengine instance. This hash table does have a configurable <br>
timeout value (`hash_table_tout`, defaults to 1 hour), which makes it <br>
possible to still use it in a way you've described. However, from the <br>
code it's my understanding that timed out hash table entries are only <br>
deleted when they're encountered during processing, so it's not entirely <br>
deterministic that old entries are always deleted after they've timed <br>
out. The RPC command `rtpengine.get_hash_total` can be used to inspect <br>
the current size of the hash table.<br>
<br>
Cheers<br>
<br>
<br>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div>