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

[Jason Penton]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20130805/8e8c2c6a/attachment.html>