<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body 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<br>
    <br>
    <div class="moz-cite-prefix">On 8/5/13 11:45 AM, Jason Penton wrote:<br>
    </div>
    <blockquote
cite="mid:CALoGXNX5gT-hxPLN4BcLT7TObvvNfJ_kDWqBnvyMYbX7Lk+EGQ@mail.gmail.com"
      type="cite">
      <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 class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
sr-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
</pre>
  </body>
</html>