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

[Jason Penton]

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 <
miconda at gmail.com> 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 <
> 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
>>
>>
>
> --
> Daniel-Constantin Mierla - http://www.asipto.comhttp://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/20130926/ed5b510f/attachment.html>