<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">Hello,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I just realized that I had the
dispatcher configured using a hash of Call-ID. That means, after
recvfrom there must be an extra processing finding the Call-ID
header in message, to calculate a hash and then forward() message.
The more the processing, the more cases when 200 could arrive
before 180. I just changed it to round robin, and the amount
decreased a lot, but it's still there. If I send a burst of 1000
messages, about 5 of them leave out of order every time.<br>
<br>
Best regards,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Luis<br>
<br>
<br>
<br>
On 4/9/20 1:48 PM, Luis Rojas G. wrote:<br>
</div>
<blockquote type="cite" cite="mid:f3f9c7bc-2c35-8d6f-2e3e-abb8510589b0@sixbell.com">
<div class="moz-cite-prefix">Hello,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I have a lot of experience developing
mutithreaded applications, and I don't see it so unlikely at all
that a process loses cpu just after recvfrom(). It's just as
probable as to lose it just before, or when writing on a cache
or just before of after sendto(). If there are many messages
going through, some of them will fall in this scenario. if I try
sending a burst of 100 messages, I see two or three presenting
the scenario.<br>
<br>
Just forward() with a single process does not give the capacity.
I'm getting almost 1000caps. More than that and start getting
errores, retransmissions, etc. And this is just one way. I need
to receive the call to go back to the network (our application
is a B2BUA), so I will be down to 500caps, with a simple
scenario, with no reliable responses, reinvites, updates, etc. I
will end up having as many standalone kamailio processes as the
current servers I do have now.<br>
<br>
I really think the simplest way would be to add a small delay to
200 OK. Very small, like 10ms, should be enough. Simple and it
should work. As Alex Balashov commented he did for the case with
ACK-Re-Invite. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I have to figure out how to make
async_ms_sleep() work in reply_route().<br>
<br>
Thanks for all the comments and ideas<br>
<br>
Best regards,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Luis<br>
<br>
<br>
<br>
. On 4/9/20 12:17 PM, Daniel-Constantin Mierla wrote:<br>
</div>
<blockquote type="cite" cite="mid:2e1c8786-a7e2-0487-17f7-66348c91af1b@gmail.com">
<table id="msexchangeipsafetytips;2be8e9d7-86c6-497d-159b-08d7dca18936;R:en-US" style="cellpadding:0;border:0;cellspacing:0;display:table;width:100%;table-layout:fixed;border-collapse:seperate;float:none;" width="100%" cellspacing="0" cellpadding="0" border="0" align="left">
<tbody>
<tr>
<td cellpadding="7px 2px 7px 2px" style="padding:7px 2px
7px 2px;background-color:#A6A6A6;valign:middle" width="1px" valign="middle" bgcolor="#A6A6A6"> <br>
</td>
<td cellpadding="7px 5px 7px 15px" color="#212121" style="width:100%;background-color:#EAEAEA;padding:7px
5px 7px 15px;font-family:wf_segoe-ui_normal,Segoe
UI,Segoe WP,Tahoma,Arial,
sans-serif;font-size:12px;font-weight:normal;color:#212121;text-align:left;word-wrap:break-word;" width="100%" valign="middle" bgcolor="#EAEAEA">
<div><a class="moz-txt-link-abbreviated" href="mailto:MICONDA@GMAIL.COM" moz-do-not-send="true">MICONDA@GMAIL.COM</a> appears
similar to someone who previously sent you email, but
may not be that person. <a href="http://aka.ms/LearnAboutSenderIdentification" moz-do-not-send="true">Learn why this could be a
risk</a></div>
</td>
<td cellpadding="7px 5px 7px 5px" color="#212121" style="width:75px;background-color:#EAEAEA;padding:7px
5px 7px 5px;font-family:wf_segoe-ui_normal,Segoe
UI,Segoe WP,Tahoma,Arial,
sans-serif;font-size:12px;font-weight:normal;color:#212121;text-align:left;word-wrap:break-word;align:left" width="75px" valign="middle" bgcolor="#EAEAEA" align="left"> <a href="http://aka.ms/SafetyTipsFeedback" moz-do-not-send="true">Feedback</a></td>
</tr>
</tbody>
</table>
<div>
<p>Hello,</p>
<p>then the overtaking is in between reading from the socket
and getting to parsing the call-id value -- the cpu is lost
by first reader after recvfrom() and the second process get
enough cpu time to go ahead further. I haven't encountered
this case, but as I said previously, it is very unlikely,
but still possible. I added the route_locks_size because in
the past I had cases when processing of some messages took
longer executing config (e.g., due to authentication,
accounting, ..) and I needed to be sure they are processed
in the order they enter config execution.<br>
</p>
<p>Then the option is to see if a single process with
stateless sending out (using forward()) gives the capacity,
if you don't do any other complex processing. Or if you do
more complex processing, use a dispatcher process with
forwarding to local host or in a similar manner try to use
mqueue+rtimer for dispatching using shared memory queues.</p>
<p>Of course, it is open source and there is also the C coding
way, to add a synchronizing mechanism to protect against
parallel execution of the code from recvfrom() till call-id
lock is acquired.</p>
<p>Cheers,<br>
Daniel<br>
</p>
</div>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
<a class="moz-txt-link-freetext" href="mailto:luis.rojas@sixbell.com">mailto:luis.rojas@sixbell.com</a>
<a class="moz-txt-link-freetext" href="http://www.sixbell.com">http://www.sixbell.com</a></pre>
</body>
</html>