[test-results] [Bamboo] Asterisk > 1.6.2 - Linux - i686 > #73 was SUCCESSFUL (with 8 tests). Change made by Russell Bryant.

[Bamboo]

-------------- next part --------------
-----------------------------------------------------------------------
Asterisk > 1.6.2 - Linux - i686 > #73 was successful.
-----------------------------------------------------------------------
Code has been updated by Russell Bryant.
8 tests in total.

http://bamboo.asterisk.org/browse/AST-16232-73/


--------------
Code Changes
--------------
Russell Bryant (296001):

>Merged revisions 296000 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.4
>
>........
>  r296000 | russell | 2010-11-24 10:48:39 -0600 (Wed, 24 Nov 2010) | 38 lines
>  
>  Handle failures building translation paths more effectively.
>  
>  The problem scenario occurred on a heavily loaded system that was using the
>  codec_dahdi module and exceeded the hardware transcoding capacity.  The failure
>  mode at that point was not good.  The report came in to us as an Asterisk
>  lock-up.  The "core show locks" shows a ton of threads locked up (but no
>  obvious deadlock).  Upon deeper investigation, when the system is in this
>  state, the CPU was maxed out.  The CPU was being consumed by the Asterisk
>  logger spewing messages on every audio frame for calls set up after transcoder
>  capacity was reached.
>  
>  The purpose of this patch is to make Asterisk handle failures to create a
>  translation path in a more graceful manner.  If we can't translate, then the
>  call just needs to be dropped, as it's not going to work.  These are the
>  changes:
>  
>  1) In set_format() of channel.c (which is called by set_read_format() and
>  set_write_format()), it was ignoring if ast_translator_build_path() failed and
>  returned NULL.  It now pays attention to that case and returns a result
>  reflecting failure.  With this change in place, the bridging code will
>  immediately detect a failure and end the bridge instead of proceeding to try to
>  bridge frames that can't be translated and making channel drivers freak out by
>  sending them frames in a format they weren't expecting.
>  
>  2) In ast_indicate_data() of channel.c, failure of ast_playtones_start() was
>  ignored.  It is now reflected in the return value of the function.  This didn't
>  turn out to have any affect on the bug, but seemed like a good change to leave
>  in.
>  
>  3) In app_dial(), when only sending a call to a single endpoint, it will
>  attempt to do some bridging of its own of early audio.  It uses
>  make_compatible() when it's going to do this.  However, it ignored failure from
>  make compatible.  So, even with the fix from #1, if there was early audio going
>  through app_dial, there would still be a period of invalid frames passing
>  through.  After detecting failure here, Dial() exits.
>  
>  ABE-2658
>........
>


--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/test-results/attachments/20101124/ec57c322/attachment-0001.htm