[test-results] [Bamboo] No agents to build plan Asterisk Testing - Asterisk Trunk - Asterisk CentOS 6 64-Bit

Bamboo bamboo at asterisk.org
Tue Jul 23 13:34:50 CDT 2013


-------------------------------------------------------------------------------
TESTING-ASTERISKTRUNK-AST18CENTOS64-1566 has been queued, but there's no agent capable of building it.
-------------------------------------------------------------------------------

http://bamboo.asterisk.org/browse/TESTING-ASTERISKTRUNK-AST18CENTOS64/log

--------------
Code Changes
--------------
kmoore (395107):

>Add missing newline

dlee (395118):

>Fix bridge/channel AMI event ordering issues
>
>The stasis_cache_update messages are somewhat cumbersome to handle
>with the stasis_message_router. Since all updates have the same
>message type, they are normally handled with the same route.
>
>Since caching itself is a first class component of stasis-core, it
>makes sense for the router to handle the cache update messages itself.
>This patch adds stasis_message_router_add_cache_update() and
>stasis_message_router_remove_cache_update() to handle the routing of
>stasis_cache_update messages.
>
>This patch also corrects an issue with manager_{bridging,channels}.c,
>where events might be reordered. The reordering occurs because the
>components use different message routers, which they needed because
>they both needed to route cache update messages. They now both use
>manager's router, and add cache routes for just the cache updates they
>are interested in.
>
>(closes issue ASTERISK-22038)
>Review: https://reviewboard.asterisk.org/r/2677/
>

dlee (395120):

>Continue events when ARI WebSocket reconnects
>
>This patch addresses a bug in the /ari/events WebSocket in handling
>reconnects.
>
>When a Stasis application's associated WebSocket was disconnected and
>reconnected, it would not receive events for any channels or bridges
>it was subscribed to.
>
>The fix was to lazily clean up Stasis application registrations,
>instead of removing them as soon as the WebSocket goes away.
>
>When an application is unregistered at the WebSocket level, the
>underlying application is simply deactivated. If the application
>WebSocket is reconnected, the application is reactivated for the new
>connection.
>
>To avoid memory leaks from lingering, unused application, the
>application list is cleaned up whenever new applications are
>registered/unregistered.
>
>(closes issue ASTERISK-21970)
>Review: https://reviewboard.asterisk.org/r/2678/
>


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


More information about the Test-results mailing list