<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix"><tt>Brett,<br>
        <br>
        The timeout for the async ops will be control by the reactor
        (like triggering the timouts) and set by the module starting the
        op - like the rest_client module will set the timeout for the
        HTTP rest queries.<br>
        <br>
        The processes are not suspended, just the context of an
        execution. So at the end is just about memory - of course there
        should be a safety net to limit the number of suspended async
        I/Os per type of I/O. Each type of I/O op will have a priority
        in relation to other I/O ops (like timer jobs higher than aysnc
        resume, async resume higher than reading from network).<br>
        <br>
        An async I/O is done during handling a SIP message, so it does
        not interfere with TM timers (which are activated only when
        sending the traffic out). otherwise the dialogs and transactions
        (with their eco-system) are not affected at all.<br>
        <br>
        Regards, <br>
      </tt>
      <pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
      On 02.09.2014 19:53, Brett Nemeroff wrote:<br>
    </div>
    <blockquote
cite="mid:CAPwC5wwTrasBzVw+QijAmJ9xefH808rqUtAD3gX0xTQp3fVTdA@mail.gmail.com"
      type="cite">
      <div dir="ltr">I'm curious what the failure cases look like here..
        <div>What happens when your "long running db query" is
          excessively long? Is there a timeout? What happens if you have
          1000s of backed up processes. Would love to see some sort of
          fifo command somehow quantify the effectiveness of it being
          async. Not sure how to say this right. But I'd like to be able
          to query a value that says either "bg tasks are being handled
          in a timely fashion" or "bg tasks are so slow it's starting to
          affect performance"</div>
        <div><br>
        </div>
        <div>Of course, these are not "normal" cases... wondering how
          "graceful" we can allow it to be broken. I assume that the
          context saving will take X memory and eventually it will fill
          up? Where is that memory stored? How is it allocated? How much
          memory do you need for each backgrounded task?</div>
        <div><br>
        </div>
        <div>Another thought..  how are dialog/transaction "variables"
          handled? AVPs? "vars"? How are dialogs handled across such an
          operation? What about standard (SIP) timer operations? What
          about dialog fr_timer and fr_inv_timer, do they continue to
          run?</div>
        <div><br>
        </div>
        <div>Thanks, really looking forward to async!</div>
        <div>-Brett</div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Tue, Sep 2, 2014 at 11:26 AM, Răzvan
          Crainea <span dir="ltr">&lt;<a moz-do-not-send="true"
              href="mailto:razvan@opensips.org" target="_blank">razvan@opensips.org</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
            <br>
            Among the last discussion of the last IRC meeting[1] was
            related to Asynchronous processing in OpenSIPS script - we
            want to add a new mechanism that allows you to perform
            asynchronous operations (such as DB , REST or exec
            operations) directly from the script. Using this feature
            will increase the throughput of OpenSIPS, since the SIP
            processes will no longer be stuck waiting for I/O responses.<br>
            <br>
            When reaching an asynchronous operation, the SIP message
            processing will be stopped, and resumed in a different
            script route. In the script, this should be reflected
            something like this:<br>
            <br>
            route {<br>
                ...<br>
                # other non I/O operations<br>
                async(my_resume_route) {<br>
                    avp_db_query("SELECT setid from subscribers where
            username = '$fU'", "$avp(setid)");<br>
                }<br>
                # we never get here.<br>
                exit;<br>
            }<br>
            <br>
            route[my_resume_route] {<br>
                xlog("The set used by the callee is $avp(setid)\n");<br>
                # continue message processing<br>
            }<br>
            <br>
            Only the functions that are used in an "async" block will be
            ran asynchronously. If the function does not support async
            processing, it will block waiting for the response and
            resume in the route indicated by the "async" block - so the
            scripting experience will be the same even if the async OP
            could not be done.<br>
            In order to resume the processing in a different route, we
            need to store a context of the message. This will be done
            using the transaction module[2]. If this module is not used,
            the asynchronous mechanism will not work.<br>
            <br>
            lirakis suggested to have different processes that waits for
            the asynchronous I/O responses and continues the processing.
            However, we think having the SIP worker processes resume the
            operations will behave better, since we'll have fewer
            processes and we won't loose time with context switches.<br>
            <br>
            How do you see this feature? How would you like to use it?
            Feel free to contribute with any input you find suitable!<br>
            <br>
            [1] <a moz-do-not-send="true"
              href="http://www.opensips.org/Community/IRCmeeting20140827"
              target="_blank">http://www.opensips.org/Community/IRCmeeting20140827</a><br>
            [2] <a moz-do-not-send="true"
              href="http://www.opensips.org/html/docs/modules/1.12.x/tm"
              target="_blank">http://www.opensips.org/html/docs/modules/1.12.x/tm</a><br>
            <br>
            Best regards,<span class="HOEnZb"><font color="#888888"><br>
                <br>
                -- <br>
                Răzvan Crainea<br>
                OpenSIPS Solutions<br>
                <a moz-do-not-send="true"
                  href="http://www.opensips-solutions.com"
                  target="_blank">www.opensips-solutions.com</a><br>
                <br>
                <br>
                _______________________________________________<br>
                Users mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
                <a moz-do-not-send="true"
                  href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users"
                  target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
              </font></span></blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>