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

[Jason Penton]

Hey Daniel,

No problem. Please see attached.

Cheers
Jason



On Mon, Aug 5, 2013 at 11:07 PM, Daniel-Constantin Mierla <miconda at gmail.com
> 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 listsr-dev at lists.sip-router.orghttp://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
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20130808/0c39126d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tm-async-changes.diff
Type: application/octet-stream
Size: 19798 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20130808/0c39126d/attachment-0001.obj>