[test-results] [Bamboo] Asterisk Testing > Asterisk Trunk > #301 has FAILED. Change made by 5 authors.

[Bamboo]

-----------------------------------------------------------------------
Asterisk Testing > Asterisk Trunk > #301 failed.
-----------------------------------------------------------------------
Code has been updated by Terry Wilson, Mark Michelson, Matthew Jordan, rmudgett, Kinsey Moore.
No failed tests found, a possible compilation error.

http://bamboo.asterisk.org/browse/TESTING-ASTERISKTRUNK-301/


--------------
Failing Jobs
--------------
  - Asterisk CentOS 6 64-Bit (CentOS 6): 93 tests passed.



--------------
Code Changes
--------------
Matthew Jordan (367376):

>Re-add LastMsgsSent value for SIP peers
>
>Previously, MWI logic utilized a counter called 'lastmsgssent' to know whether
>or not MWI NOTIFY requests had been sent to a specific peer.  When MWI
>notifications were changed to use the internal event framework, this value was
>no longer needed for its original purpose.  Hence, it was no longer updated
>with the new/old message counts for a peer.  The value was previously removed
>for Asterisk 10; however, since it was still present in Asterisk 1.8 and still
>useful for reporting purposes, it was decided to re-add the value.
>
>This patch re-adds the 'LastMsgsSent' field in the response to an AMI/CLI 'sip
>show peer [peer]' command, and makes it so that the value of lastmsgssent is
>updated appropriately. The value should now display the new/old message counts
>for a particular peer.
>
>(closes issue ASTERISK-17866)
>Reported by: Steve Davies
>patches by:
>  ast-17866-rb1272.patch (License #5041 by irroot)
>  Modified slightly for this commit
>
>Review: https://reviewboard.asterisk.org/r/1939
>........
>
>Merged revisions 367362 from http://svn.asterisk.org/svn/asterisk/branches/1.8
>........
>
>Merged revisions 367369 from http://svn.asterisk.org/svn/asterisk/branches/10
>

Terry Wilson (367309):

>Fix race condition for CEL LINKEDID_END event
>
>This patch fixes to situations that could cause the CEL LINKEDID_END event to
>be missed.
>
>1) During a core stop gracefully, modules are unloaded when ast_active_channels
>== 0. The LINKDEDID_END event fires during the channel destructor. This means
>that occasionally, the cel_* module will be unloaded before the channel is
>destroyed. It seemed generally useful to wait until the refcount of all
>channels == 0 before unloading, so I added a channel counter and used it in the
>shutdown code.
>
>2) During a masquerade, ast_channel_change_linkedid is called. It calls
>ast_cel_check_retire_linkedid which unrefs the linkedid in the linkedids
>container in cel.c. It didn't ref the new linkedid. Now it does. 
>
>Review: https://reviewboard.asterisk.org/r/1900/
>........
>
>Merged revisions 367292 from http://svn.asterisk.org/svn/asterisk/branches/1.8
>........
>
>Merged revisions 367299 from http://svn.asterisk.org/svn/asterisk/branches/10
>

rmudgett (367227):

>Made ast_queue_hangup() and ast_queue_hangup_with_cause() lock instead of trylock.
>
>It made no sense to trylock the channel and then unconditionally lock the
>channel right after.
>



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