<font face="arial" size="2"><p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">hello Daniel</p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">Thanks a lot for the update. We will also test it.</p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">It has not 100% relation with this issue, but i only wanted to share the setup we have for cases where a rtpengine fails having high traffic load, to minimize the impact on the kamailio processes.</p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">modparam("rtpengine", "queried_nodes_limit", 2)<br />modparam("rtpengine", "rtpengine_retr", 2)<br />modparam("rtpengine", "rtpengine_tout_ms", 350)</p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">considering we don't use sets with more than 2 rtpengine instances, at least for retry attempts. And your rtpengine instances are in the same network too.</p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">this works quite fine for us, there are some few secs of impact while the rtpengine is marked as disabled, but the system recovers quite ok.</p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">best regards</p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">david</p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">-----Original Message-----<br />From: "Daniel-Constantin Mierla" <miconda@gmail.com><br />Sent: Friday, December 28, 2018 9:15am<br />To: "Juha Heinanen" <jh@tutpro.com><br />Cc: "Kamailio (SER) - Users Mailing List" <sr-users@lists.kamailio.org><br />Subject: Re: [SR-Users] kamailio does not responde if an rtpengine is unreachable<br /><br /></p>
<div id="SafeStyles1546076536">
<p style="margin:0;padding:0;margin: 0; padding: 0; font-family: arial; font-size: 10pt; overflow-wrap: break-word;">I just pushed a series of commits trying to rework how loading (and<br />reloading) of rtpegines list is done, to avoid that sync'ed probing,<br />which can take long if any of the rtpengines is down.<br /><br />Now, building the local (per process) structures/sockets for rtpengines<br />during kamailio start up is done without locking. This is guarded by the<br />fact a reload command can be executed only after all children were<br />initialized (added also with these commits). Moreover, the probing of<br />rtpeningesis done only by child process 1, because the status is stored<br />in shared memory list, so it is visible in all children. Based on my<br />understanding there, doing probing from all processes is useless now,<br />that was probably kept from the time when the list was not stored in<br />shared memory, from the early rtpproxy times.<br /><br />There is also a restriction on how often the rtpengine list can be<br />reloaded, now having a 10 seconds interval guard. I added this because<br />the reload is done over the old list, not building a new list to swap<br />with the old one. So it requires some time to walk through the existing<br />list and update based on the new records. I went this way for now, even<br />building a new list may be better/safer in long term, but it would<br />require more work. I also wanted to avoid being very intrusive right<br />now, given that those patches would need to be backported.<br /><br />The last relevant change was to use a version number to discover when a<br />reload was done. So far, as I understood, it was relying on the number<br />of rtpengines, but one may trigger a reload with same rtpengines, but<br />different attributes (e.g., disabled or not). Having a version number is<br />better in detecting when each worker needs to rebuild its local list of<br />sockets, as well as for troubleshooting, because a value is increased<br />with each reload, so easier to track if it was done or now.<br /><br />I didn't have time for any tests, so it would be good if you can test<br />and report if works as expected.<br /><br />All related commits are in master, if they prove to work fine, we can<br />backport all those patches.<br /><br />Cheers,<br />Daniel<br /><br />On 26.12.18 12:46, Juha Heinanen wrote:<br />> Daniel-Constantin Mierla writes:<br />><br />>> I pushed a quick fix for the case when db support is not enabled,<br />>> because these locks are useless in that case, so all children will do<br />>> the rtpengine init at the same time, without waiting for the others:<br />> Still took in rtpengine db mode about 2 minutes before kamailio became<br />> responsive after start.<br />><br />> -- Juha<br /><br />-- <br />Daniel-Constantin Mierla -- www.asipto.com<br />www.twitter.com/miconda -- www.linkedin.com/in/miconda<br />Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com<br />Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com<br /><br /><br />_______________________________________________<br />Kamailio (SER) - Users Mailing List<br />sr-users@lists.kamailio.org<br />https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</p>
</div>
<p style="margin:0;padding:0;font-family: arial; font-size: 10pt; overflow-wrap: break-word;"> </p></font>