On Wed, Sep 5, 2018 at 5:23 PM Seán C. McCord <[email protected]> wrote:
> As to the events should have a deterministic order or not, I cannot speak, > but this is definitely normal behaviour. > > > On Wed, Sep 5, 2018 at 12:22 PM Jean Aunis <[email protected]> wrote: > >> Hello, >> >> It looks like the ARI events ordering during channel destruction is not >> deterministic. I noticed this for ChannelLeftBridge and ChannelDestroyed >> events : given a channel is in a bridge and is hanged up, sometimes >> ChannelLeftBridge is raised before ChannelDestroyed, sometimes it's the >> contrary. Test conditions are exactly the same in both cases. >> >> Is this non-deterministic behaviour normal, or should it be considered as >> a bug ? >> >> To my mind, ChannelDestroyed should always be the very last event raised >> for a given channel. From a developper point of view, it would give a clear >> indication that the resources associated to the channel can be freed. >> >> Regards >> > The events regarding a Channel entering and leaving a Bridge are deterministic with respect to the Bridge's lifetime, but are not deterministic with respect to the Channel's lifetime. While it's a bit different, this is discussed somewhat on the AMI specification page: https://wiki.asterisk.org/wiki/display/AST/AMI+v2+Specification#AMIv2Specification-Bridging While AMI and ARI are two different APIs, both are built on top of a shared internal abstraction layer inside Asterisk that determines that event ordering. In the case of channels, channel event ordering is guaranteed when those events are published to what is known as the 'channel' topic for that channel. The act of entering / leaving a bridge is published to the bridge's topic, which is technically independent of the channel's topic. As such, the ordering of those events as they are presented to the AMI / ARI topics is not guaranteed. An example can be seen in publishing the bridge leave message: void ast_bridge_publish_leave(struct ast_bridge *bridge, struct ast_channel *chan) { struct stasis_message *msg; if (ast_test_flag(&bridge->feature_flags, AST_BRIDGE_FLAG_INVISIBLE)) { return; } msg = ast_bridge_blob_create(ast_channel_left_bridge_type(), bridge, chan, NULL); if (!msg) { return; } /* state first, then leave blob (opposite of enter, preserves nesting of events) */ bridge_publish_state_from_blob(bridge, stasis_message_data(msg)); stasis_publish(ast_bridge_topic(bridge), msg); ao2_ref(msg, -1); } Note that we're publishing that message to the bridge topic - ast_bridge_topic(bridge) - as opposed to the channel topic (which would be ast_channel_topic(chan)). (To be pedantic, if you really wanted to preserve event ordering for both the bridge and the channel's respective lifetimes, you'd have to make a new aggregation topic for each channel / bridge and publish their messages to those aggregation topics, but that's a lot of overhead.) You could argue that it *should* be ordered with respect to both the channel and bridge's lifetime, but generally enforcing that ordering imposes a penalty on the system, as it requires more synchronization. If someone went down that path, it'd require some careful testing to ensure it doesn't bog things down in some massive way. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Astricon is coming up October 9-11! Signup is available at: https://www.asterisk.org/community/astricon-user-conference asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
