[asterisk-dev] ARI events order

[Jean Aunis]

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

Ingénieur R&D
R&D engineer

Tel : [phone]
Standard: [phone]


   Rue de Broglie
   22300 LANNION
   FRANCE
www.prescom.fr <http://www.prescom.fr/>

/"Les informations contenues dans ce courrier sont données à titre
purement informatif et ne peuvent être considérées comme contractuelles
entre les récipiendaires,
la société PRESCOM." //"The content of this e-mail is purely for
information and may not be considered as contractual between the
recipients, PRESCOM company."/

[Seán C. McCord]

As to the events should have a deterministic order or not, I cannot speak,
but this is definitely normal behaviour.

Post by Jean Aunis
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
--
Jean AUNIS
Ingénieur R&D
R&D engineer
Tel : [phone] <+33%201%2030%2085%2090%2022>
Standard: [phone]
Rue de Broglie
22300 LANNION
FRANCE
www.prescom.fr <http://www.prescom.fr/>
*"Les informations contenues dans ce courrier sont données à titre
purement informatif et ne peuvent être considérées comme contractuelles
entre les récipiendaires, la société PRESCOM." **"The content of this
e-mail is purely for information and may not be considered as contractual
between the recipients, PRESCOM company."*
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
https://www.asterisk.org/community/astricon-user-conference
asterisk-dev mailing list
http://lists.digium.com/mailman/listinfo/asterisk-dev

[Matthew Jordan]

Post by Seán C. McCord
As to the events should have a deterministic order or not, I cannot speak,
but this is definitely normal behaviour.

Post by Jean Aunis
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.

[Jean Aunis]

Post by Seán C. McCord
As to the events should have a deterministic order or not, I
cannot speak, but this is definitely normal behaviour.
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
<snip>

Thanks for the answer, I understand the problem. I'll live with it.

Regards

Jean