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

[Daniel-Constantin Mierla]

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 
> <miconda at gmail.com <mailto: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 list
>>     sr-dev at lists.sip-router.org  <mailto: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://twitter.com/#%21/miconda>  -http://www.linkedin.com/in/miconda
>
>
>     _______________________________________________
>     sr-dev mailing list
>     sr-dev at lists.sip-router.org <mailto: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/20130821/37510d8d/attachment-0001.html>