[asterisk-dev] [Code Review] 4163: Stasis: Fix StasisEnd message ordering

[Mark Michelson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4163/#review13736
-----------------------------------------------------------


As a general comment, I suggest adding errror messages for all off-nominal paths when it comes to sending StasisStart or StasisEnd events. If these messages don't get sent, it's really helpful to be able to inspect the logs and figure out what went wrong.

- Mark Michelson


On Nov. 12, 2014, 3:58 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4163/
> -----------------------------------------------------------
> 
> (Updated Nov. 12, 2014, 3:58 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24501
>     https://issues.asterisk.org/jira/browse/ASTERISK-24501
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This change corrects message ordering in cases where a channel-related message can be received after a Stasis/ARI application has received the StasisEnd message. The StasisEnd message was being passed to applications directly without waiting for the channel topic to empty.
> 
> As a result of this fix, other bugs were also identified and fixed:
> * StasisStart messages were also being sent directly to apps and are now routed through the stasis message bus properly
> * Masquerade monitor datastores were being removed at the incorrect time in some cases and were causing StasisEnd messages to not be sent
> * General refactoring where necessary for the above
> * Unsubscription on StasisEnd timing changes to prevent additional messages from following the StasisEnd when they shouldn't
> 
> A channel sanitization function pointer was added to reduce processing and AO2 lookups
> 
> This also required minor changes to tests using AriTestObject or its subclasses since StasisEnd is no longer reliably received before the test shuts the websocket down. This is due to the AriTestObject relying on AMI events to decide when the test is over which won't necessarily come in at the same time as the corresponding ARI events since they arrive via two different transports.
> 
> 
> Diffs
> -----
> 
>   branches/12/res/stasis/stasis_bridge.c 427539 
>   branches/12/res/stasis/app.c 427539 
>   branches/12/res/stasis/app.h 427539 
>   branches/12/res/res_stasis.c 427539 
>   branches/12/include/asterisk/stasis_app.h 427539 
>   branches/12/include/asterisk/stasis.h 427539 
> 
> Diff: https://reviewboard.asterisk.org/r/4163/diff/
> 
> 
> Testing
> -------
> 
> Ran all the REST API tests to verify that they passed.
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141112/ca210efc/attachment.html>