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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
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
_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
