<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:12px">Hi Daniel,</span><div style="font-family:arial,sans-serif;font-size:12px"><br></div><div style="font-family:arial,sans-serif;font-size:12px">Sorry for delay on this....</div>
<div style="font-family:arial,sans-serif;font-size:12px"><br></div><div style="font-family:arial,sans-serif;font-size:12px">No, the blind UAC is still added. This is needed to be able to run fr_timer.... There aren't really any changes in the suspend code, but rather in the continue code.</div>
<div style="font-family:arial,sans-serif;font-size:12px"><br></div><div style="font-family:arial,sans-serif;font-size:12px">Summary of the changes:</div><div style="font-family:arial,sans-serif;font-size:12px">1. In continue code, we no longer take reply lock. There is now a new lock (async_continue). This allows us to send replies on continue</div>
<div style="font-family:arial,sans-serif;font-size:12px">2. Transaction has an extra flag (T_ASYNC_CONTINUE). This allows us to know in any code in kamailio if we are executing in a continuation of an <span class="">async</span> transaction</div>
<div style="font-family:arial,sans-serif;font-size:12px">3. We don't set the "t->uac[branch].last_received=500" of the blind UAC anymore. If we did then any replies coming back will not be relayed (because the transaction would 'appear' complete (500)).</div>
<div style="font-family:arial,sans-serif;font-size:12px"><br></div><div style="font-family:arial,sans-serif;font-size:12px">I will put the patch in today and you can check the diff?</div><div style="font-family:arial,sans-serif;font-size:12px">
<br></div><div style="font-family:arial,sans-serif;font-size:12px">Cheers</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 21, 2013 at 12:50 AM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hi Jason,<br>
<br>
if I understand correctly, now the suspend doesn't create a blind
uac anymore, am I right? It is a normal branch that can be forwarded
and can get replies (previously was marked with a fake 500 reply
code). Was it a specific reason for it?<br>
<br>
Otherwise the patch looks ok, it can be pushed to master so people
can get enough time to play with it.<br>
<br>
Cheers,<br>
Daniel<div><div class="h5"><br>
<br>
<div>On 8/8/13 8:49 AM, Jason Penton wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hey Daniel,
<div><br>
</div>
<div>No problem. Please see attached.</div>
<div><br>
</div>
<div>Cheers</div>
<div>Jason</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
On Mon, Aug 5, 2013 at 11:07 PM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Hi Jason,<br>
<br>
would you make a single patch for tm module out of your
branch and send it over to the list for review? It would
be easier to spot the changes...<br>
<br>
Thanks,<br>
Daniel
<div>
<div><br>
<br>
<div>On 8/5/13 11:45 AM, Jason Penton wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<div dir="ltr">Hi guys..... more specifically, TM
experts ;)
<div><br>
</div>
<div>I have just committed a tmp branch called
tm_async_extensions. We noticed with the current
async impl, it is not possible to do things like
forward() and t_relay() in a continued async
route block. This is mainly because the faked
env. created is specifically triggered to be a
failure route in the continuation code.</div>
<div><br>
</div>
<div>We have changed this to execute the route
block using the original block type when the
transaction was suspended (eg REQUEST_ROUTE,
ON_REPLY, etc). We have also tested using reply
blocks (ie suspending replies) but that code
will come later once everyone is happy that we
include the current subset of changes to improve
normal async REQUEST processing. </div>
<div><br>
</div>
<div>The current changes require some changes to
the main TM structure (mainly for 'backing up'
state before suspending). There is also a new
mutex used to prevent multiple concurrent
invocations of t_continue (previously we were
using the reply lock).</div>
<div><br>
</div>
<div>It would be great if some TM experts could
review the code to ensure there are no use cases
that we have missed that could break things.
Daniel I suspect you know TM and its impacts the
best, or is there someone else we should
include?</div>
<div><br>
</div>
<div>So far for our use cases, these changes work
great. We can do things like:</div>
<div><br>
</div>
<div>
<div><font face="courier new, monospace">route[INVITE]
{</font></div>
<div><font face="courier new, monospace">
t_newtran();</font></div>
<div><font face="courier new, monospace">
async_route("INVITERESUME", "10");
#resume transaction in 10 seconds running
route block INVITERESUME</font></div>
<div><font face="courier new, monospace">
exit;</font></div>
<div><font face="courier new, monospace">}</font></div>
<div><font face="courier new, monospace"><br>
</font></div>
<div><font face="courier new, monospace">route[INVITERESUME]
{</font></div>
<div><font face="courier new, monospace">
t_relay();</font></div>
<div><font face="courier new, monospace">}</font></div>
<div><br>
</div>
<div>All upstream reply processing is correctly
handled, local ACK generation and processing
works as expected, etc. </div>
<div><br>
</div>
<div> The above example may seem absurd (why
would we want to delay our proxy of an INVITE
for 10 seconds????) - Well this is just an
easy example we use in our test cases.
Actually we are using the async processing in
the IMS code to increase performance when an
INVITE for example triggers a long running
process (like a DIAMETER request to get a
users profile for example). Using conventional
methods (no async transactions), the SIP
worker process will sit locked up for this
time (maybe 100's of milliseconds)
unnecessarily. We found that using t_suspend
and t_continue internally in our code improves
performance significantly. I can see many use
cases for the async code to improve
performance, especially cases where we use
backend DB's, memcached, radius, diameter, etc
before actually "doing SIP routing".....</div>
<div><br>
</div>
<div>Any feedback would be greatly appreciated.</div>
<div><br>
</div>
<div>Cheers</div>
<div>Jason</div>
</div>
<div><br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
sr-dev mailing list
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><span><font color="#888888">
</font></span></pre>
<span><font color="#888888"> </font></span></blockquote>
<span><font color="#888888"> <br>
<pre cols="72">--
Daniel-Constantin Mierla - <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
<a href="http://twitter.com/#%21/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a>
</pre>
</font></span></div>
<br>
_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre cols="72">--
Daniel-Constantin Mierla - <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
<a href="http://twitter.com/#!/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a>
</pre>
</div></div></div>
</blockquote></div><br></div>