Hi Daniel, Sorry for delay on this....
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. Summary of the changes: 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 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 async transaction 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)). I will put the patch in today and you can check the diff? Cheers On Wed, Aug 21, 2013 at 12:50 AM, Daniel-Constantin Mierla < [email protected]> wrote: > Hi Jason, > > 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? > > Otherwise the patch looks ok, it can be pushed to master so people can get > enough time to play with it. > > Cheers, > Daniel > > > On 8/8/13 8:49 AM, Jason Penton wrote: > > Hey Daniel, > > No problem. Please see attached. > > Cheers > Jason > > > > On Mon, Aug 5, 2013 at 11:07 PM, Daniel-Constantin Mierla < > [email protected]> wrote: > >> Hi Jason, >> >> 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... >> >> Thanks, >> Daniel >> >> >> On 8/5/13 11:45 AM, Jason Penton wrote: >> >> Hi guys..... more specifically, TM experts ;) >> >> 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. >> >> 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. >> >> 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). >> >> 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? >> >> So far for our use cases, these changes work great. We can do things >> like: >> >> route[INVITE] { >> t_newtran(); >> async_route("INVITERESUME", "10"); #resume transaction in 10 >> seconds running route block INVITERESUME >> exit; >> } >> >> route[INVITERESUME] { >> t_relay(); >> } >> >> All upstream reply processing is correctly handled, local ACK >> generation and processing works as expected, etc. >> >> 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"..... >> >> Any feedback would be greatly appreciated. >> >> Cheers >> Jason >> >> >> >> _______________________________________________ >> sr-dev mailing >> [email protected]http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >> >> >> -- >> Daniel-Constantin Mierla - >> http://www.asipto.comhttp://twitter.com/#!/miconda - >> http://www.linkedin.com/in/miconda >> >> >> _______________________________________________ >> sr-dev mailing list >> [email protected] >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >> >> > > -- > Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda > - http://www.linkedin.com/in/miconda > >
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
