<div dir="ltr"><div dir="ltr"><div>Hello,</div><div><br></div><div>OK, so the reason to dump all contacts periodically from the Kamailio memory is that I have a task to monitor the network latency for every extension, which in this case we can do with the KA function from the usrloc module. <br></div><div>This information it's not in the DB, we can get this information either from the kamailio memory, or by parsing the log file. I was thinking that the first option can be better because for the second one Kamailio will have to do a lot of IO operation to the disk, which can affect somehow the performance, even if the local storage it's based on SSD's.</div><div>I was trying to use dgram for this case - but I'm not getting any output from the kamailio by sending any request.</div><div><br></div><div>For ex the following command:<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>echo '{"id": "1", "jsonrpc": "2.0", "method": "core.psx" }' > /dev/udp/<a href="http://127.0.0.1/8090">127.0.0.1/8090</a></div></blockquote><div><br></div><div>gave the following output to the log file:<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Oct  8 11:20:47 devsrv devsrv[11468]: DEBUG: jsonrpcs [jsonrpcs_sock.c:608]: jsonrpc_dgram_server(): received {"jsonrpc": "2.0", "method": "<a href="http://core.ps">core.ps</a>", "id": 1}<br>Oct  8 11:20:47 devsrv devsrv[11468]: DEBUG: jsonrpcs [jsonrpcs_sock.c:620]: jsonrpc_dgram_server(): buf is {"jsonrpc": "2.0", "method": "<a href="http://core.ps">core.ps</a>", "id": 1}#012 and we have received 48 bytes<br>Oct  8 11:20:47 devsrv devsrv[11468]: DEBUG: jsonrpcs [jsonrpcs_sock.c:629]: jsonrpc_dgram_server(): command executed - result: [200] [0x18b5430] [{#012#011"jsonrpc":#011"2.0",#012#011"result":#011[11432, "main process - attendant", 11434, "udp receiver child=0 sock=<a href="http://127.0.0.1:5060">127.0.0.1:5060</a>", 11435, "udp receiver child=1 sock=<a href="http://127.0.0.1:5060">127.0.0.1:5060</a>", 11436, "udp receiver child=0 sock=<a href="http://172.16.50.231:5060">172.16.50.231:5060</a>", 11437, "udp receiver child=1 sock=<a href="http://172.16.50.231:5060">172.16.50.231:5060</a>", 11438, "udp receiver child=2 sock=<a href="http://172.16.50.231:5060">172.16.50.231:5060</a>", 11439, "udp receiver child=3 sock=<a href="http://172.16.50.231:5060">172.16.50.231:5060</a>", 11440, "udp receiver child=4 sock=<a href="http://172.16.50.231:5060">172.16.50.231:5060</a>", 11441, "udp receiver child=5 sock=<a href="http://172.16.50.231:5060">172.16.50.231:5060</a>", 11442, "udp receiver child=6 sock=<a href="http://172.16.50.231:5060">172.16.50.231:5060</a>", 11443, "udp receiver child=7 sock=<a href="http://172.16.50.231:5060">172.16.50.231:5060</a>", 11444, "udp receiver child=0 sock=<a href="http://192.168.0.10:5060">192.168.0.10:5060</a>", 11445, "udp receiver child=1sock=<a href="http://192.168.0.10:5060">192.168.0.10:5060</a>", 11446, "udp receiver child=2 sock=<a href="http://192.168.0.10:5060">192.168.0.10:5060</a>", 11447, "udp receiver child=3 sock=<a href="http://192.168.0.10:5060">192.168.0.10:5060</a>", 11448, "udp receiver child=4 sock=<a href="http://192.168.0.10:5060">192.168.0.10:5060</a>", 11449, "udp receiver child=5 sock=<a href="http://192.168.0.10:5060">192.168.0.10:5060</a>", 11450, "udp receiver child=6 sock=<a href="http://192.168.0.10:5060">192.168.0.10:5060</a>", 11451, "udp receiver child=7 sock=<a href="http://192.168.0.10:5060">192.168.0.10:5060</a>", 11452, "udp receiver child=0 sock=<a href="http://192.168.0.10:5090">192.168.0.10:5090</a>", 11453, "udp receiver child=1 sock=<a href="http://192.168.0.10:5090">192.168.0.10:5090</a>", 11454, "udp receiver child=2 sock=<a href="http://192.168.0.10:5090">192.168.0.10:5090</a>", 11455, "udp receiver child=3 sock=<a href="http://192.168.0.10:5090">192.168.0.10:5090</a>", 11456, "udp receiver child=4 sock=<a href="http://192.168.0.10:5090">192.168.0.10:5090</a>", 11457, "udp receiver child=5 sock=<a href="http://192.168.0.10:5090">192.168.0.10:5090</a>", 11458, "udp receiver child=6 sock=<a href="http://192.168.0.10:5090">192.168.0.10:5090</a>", 11459, "udp receiver child=7 sock=<a href="http://192.168.0.10:5090">192.168.0.10:5090</a>", 11460, "slow timer", 11461, "timer", 11462, "secondary timer", 11463, "Async Task Worker", 11464, "Async Task Worker", 11465, "Async Task Worker", 11466, "Async Task Worker", 11467, "JSONRPCS FIFO", 11468, "JSONRPCS DATAGRAM", 11469, "USRLOC Timer", 11470, "USRLOC Timer", 11471, "USRLOC Timer", 11472, "USRLOC Timer", 11473, "Dialog Clean Timer", 11474, "ctl handler", 11475, "TIMER UAC REG", 11476, "SNMP AgentX", 11478, "Http Async Worker", 11479, "tcp receiver (generic) child=0", 11480, "tcp receiver (generic) child=1", 11481, "tcp receiver (generic) child=2", 11482, "tcp receiver (generic) child=3", 11483, "tcp receiver (generic) child=4", 11484, "tcp receiver (generic) child=5", 11485, "tcp receiver (generic) child=6", 11486, "tcp receiver (generic) child=7", 11487, "tcp main process"],#012#011"id":#0111#012}]</div></blockquote><div><br></div><div>I expected to receive this output back to the udp client in this case. <br></div><div><br></div><div>Also, the following request it's not getting anything even in the log file:<br></div><div><br></div><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>echo '{"id": "1", "jsonrpc": "2.0", "method": "ul.dump" }' > /dev/udp/<a href="http://127.0.0.1/8090">127.0.0.1/8090</a></div></blockquote>

</div></div><div><br></div><div>If there is a way to have all this data directly in the database - that would be perfect (I already created a feature request for that, maybe in the next versions that will be implemented).<br></div><div><br></div><div class="gmail_quote"><div class="gmail_attr">Regards,<br></div><div dir="ltr" class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">On Wed, 7 Oct 2020 at 21:27, Henning Westerholt <<a href="mailto:hw@skalatan.de">hw@skalatan.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="DE">
<div class="gmail-m_-8129590545166823329WordSection1">
<p class="MsoNormal"><span>Hello,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Your requirement to frequently dump millions of user location entries on a loaded production system sounds a bit odd to me. Maybe you can elaborate a bit on your requirements. If you
 have the requirement to access this data frequently, maybe getting it from the database directly is the better idea. If you want to get it from kamailio, choose a module that provides the option to configure the number of children (e.g. like dgram_workers
 in jsonrpcs) and set it to a sufficient number.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Cheers,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Henning<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">-- <u></u>
<u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Henning Westerholt –
</span><span><a href="https://skalatan.de/blog/" target="_blank"><span style="color:rgb(5,99,193)" lang="EN-GB">https://skalatan.de/blog/</span></a></span><span lang="EN-GB"><u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-GB">Kamailio services –
</span><span><a href="https://gilawa.com/" target="_blank"><span style="color:rgb(5,99,193)" lang="EN-GB">https://gilawa.com</span></a></span><span>
<span lang="EN-GB"><u></u><u></u></span></span></p>
<p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p>
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0cm 0cm">
<p class="MsoNormal" style="margin-left:35.4pt"><b>From:</b> sr-users <<a href="mailto:sr-users-bounces@lists.kamailio.org" target="_blank">sr-users-bounces@lists.kamailio.org</a>>
<b>On Behalf Of </b>Ilie Soltanici<br>
<b>Sent:</b> Tuesday, October 6, 2020 12:29 AM<br>
<b>To:</b> Kamailio (SER) - Users Mailing List <<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a>><br>
<b>Subject:</b> [SR-Users] jsonrpcs - safest way to get data<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-left:35.4pt"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">Hello,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">I'm trying to periodically get all registered contacts from the Kamailio memory in the json format.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">JSONRPCS module have 3 different types of transport to get this data. I just wonder what will be the safest transport for the Kamailio to get all this data? Because all this data it's not so important, I want
 to gather it without affecting the main process or with the minimal effect on the Kamailio SIP Processing module.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">1. The HTTP transport - very useful, working async, but because it depends on the xhttp module - which works synchronously I'm afraid that for big data with contacts this type of transport can affect the kamailio
 performance.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">2. FIFO - this transport also is very fast, working locally - but it's synchronous, I'm not sure how it will affect Kamailio SIP Processing when the local database will have few millions of users registered.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">3. DGRAM - also seems to be very fast, working locally or remotely through the UDP protocol, but again it's synchronous and I'm not sure that this transport is returning any output for the request, I tried - but
 didn't get back anything, while for changing something it worked fine. Maybe it was a misconfiguration in my config file.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">What would be your recommendation for this case?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:35.4pt">Thank you.<u></u><u></u></p>
</div>
</div>
</div>
</div>

</blockquote></div></div>