[test-results] [Bamboo] Asterisk > 1.4 - Linux - x86_64 > #195 has FAILED (7 tests failed). Change made by Russell Bryant.

[Bamboo]

-------------- next part --------------
-----------------------------------------------------------------------
Asterisk > 1.4 - Linux - x86_64 > #195 failed.
-----------------------------------------------------------------------
Code has been updated by Russell Bryant.
7/47 tests failed.

http://bamboo.asterisk.org/browse/AST-14-195/


--------------
Failing Jobs
--------------
  - Default Job (Default Stage): 7 of 47 tests failed.


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

>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
>


--------------
Tests
--------------
New Test Failures (7)
   - AsteriskTestSuite: Cdr/console fork after busy forward
   - AsteriskTestSuite: Cdr/console dial sip busy
   - AsteriskTestSuite: Cdr/console dial sip answer
   - AsteriskTestSuite: Cdr/console dial sip transfer
   - AsteriskTestSuite: Mixmonitor
   - AsteriskTestSuite: One-step-parking
   - AsteriskTestSuite: Cdr/console fork before dial

--
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/de97ea33/attachment.htm