[test-results] [Bamboo] Asterisk > Asterisk Unit Tests > #816 has FAILED (4 tests failed, no failures were new). Change made by 5 authors.

[Bamboo]

-----------------------------------------------------------------------
Asterisk > Asterisk Unit Tests > #816 failed.
-----------------------------------------------------------------------
This build occurred because it is a dependant of AST-ATRUNKFULLBUILD-844.
2/2 jobs failed, with 4 failing tests, no failures were new.

https://bamboo.asterisk.org/bamboo/browse/AST-ATRUNKUNIT-816/

---------------------
Currently Responsible
---------------------

Corey Farrell (Automatically assigned)
John Bigelow (Automatically assigned)
Richard Mudgett (Automatically assigned)



--------------
Failing Jobs
--------------
  - CentOS 6 32-Bit Unit Testing (Unit Testing): 2 of 457 tests failed.
  - CentOS 6 64-Bit Unit Testing (Unit Testing): 2 of 457 tests failed.



--------------
Code Changes
--------------
file (427847):

>app_confbridge: Play "leader has left" sound even when musiconhold is enabled.
>
>Currently if the leader of a conference bridge leaves any participant
>that has musiconhold enabled will not hear the "leader has left" sound.
>This is because musiconhold is started and THEN the sound is played.
>
>This change makes it so that the sound is played and THEN musiconhold
>is started. This provides a better experience for users as they may not
>have known previously why they went back to musiconhold.
>
>Review: https://reviewboard.asterisk.org/r/4177/
>........
>
>Merged revisions 427844 from http://svn.asterisk.org/svn/asterisk/branches/11
>........
>
>Merged revisions 427845 from http://svn.asterisk.org/svn/asterisk/branches/12
>........
>
>Merged revisions 427846 from http://svn.asterisk.org/svn/asterisk/branches/13
>

Matt Jordan (427932):

>tests/test_cel: Unlock bridge on off nominal paths
>
>If the test fails due to memory allocation errors, we may as well attempt to
>unlock the bridge on the way out.
>........
>
>Merged revisions 427927 from http://svn.asterisk.org/svn/asterisk/branches/13
>

Mark Michelson (427873):

>Fix race condition that could result in ARI transfer messages not being sent.
>
>From reviewboard:
>
>"During blind transfer testing, it was noticed that tests were failing
>occasionally because the ARI blind transfer event was not being sent.
>After investigating, I detected a race condition in the blind transfer
>code. When blind transferring a single channel, the actual transfer
>operation (i.e. removing the transferee from the bridge and directing
>them to the proper dialplan location) is queued onto the transferee
>bridge channel. After queuing the transfer operation, the blind transfer
>Stasis message is published. At the time of publication, snapshots of
>the channels and bridge involved are created. The ARI subscriber to the
>blind transfer Stasis message then attempts to determine if the bridge
>or any of the involved channels are subscribed to by ARI applications.
>If so, then the blind transfer message is sent to the applications. The
>way that the ARI blind transfer message handler works is to first see
>if the transferer channel is subscribed to. If not, then iterate over
>all the channel IDs in the bridge snapshot and determine if any of
>those are subscribed to. In the test we were running, the lone
>transferee channel was subscribed to, so an ARI event should have been
>sent to our application. Occasionally, though, the bridge snapshot did
>not have any channels IDs on it at all. Why?
>
>The problem is that since the blind transfer operation is handled by a
>separate thread, it is possible that the transfer will have completed and
>the channels removed from the bridge before we publish the blind transfer
>Stasis message. Since the blind transfer has completed, the bridge on
>which the transfer occurred no longer has any channels on it, so the
>resulting bridge snapshot has no channels on it. Through investigation of
>the code, I found that attended transfers can have this issue too for the
>case where a transferee is transferred to an application."
>
>The fix employed here is to decouple the creation of snapshots for the transfer
>messages from the publication of the transfer messages. This way, snapshots
>can be created to reflect what they are at the time of the transfer operation.
>
>Review: https://reviewboard.asterisk.org/r/4135
>........
>
>Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
>........
>
>Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13
>



--------------
Tests
--------------
Existing Test Failures (4)
   - AsteriskUnitTests: /res/parking/dynamic parking variables
   - AsteriskUnitTests: /channels/features/test features channel dtmf
   - AsteriskUnitTests: /res/parking/dynamic parking variables
   - AsteriskUnitTests: /channels/features/test features channel dtmf

--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/test-results/attachments/20141115/15053cc6/attachment-0001.html>