[sr-dev] TM changes to support extended async usage

[Daniel-Constantin Mierla]

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 list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20130805/f7de6480/attachment.html>