[asterisk-dev] [Code Review] 3486: res_corosync: Fix module to work with Stasis

Matt Jordan reviewboard at asterisk.org
Fri May 2 14:26:38 CDT 2014


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

(Updated May 2, 2014, 2:26 p.m.)


Review request for Asterisk Developers and Russell Bryant.


Changes
-------

Added the Real Russell Bryant (as opposed to the fake one)


Bugs: ASTERISK-22372
    https://issues.asterisk.org/jira/browse/ASTERISK-22372


Repository: Asterisk


Description
-------

This patch fixes res_corosync such that it works with Asterisk 12. This restores the functionality that was present in previous versions of Asterisk, and ensures compatibility with those versions by restoring the binary message format needed to pass information from/to them.

The following changes were made in the core to support this:
 * The event system has been partially restored. All event definition and event types were pulled from Asterisk 11. Previously, we had hoped that this information would live in res_corosync; however, this approach seems to be better for a few reasons:
   (1) Theoretically, ast_events can be used by any module as a binary representation of a Stasis message. Given the structure of an ast_event object, that information has to live in the core to be used universally. For example, defining the payload of a device state ast_event in res_corosync could result in an incompatible device state representation in another module.
   (2) Much of this representation already lived in the core, and was not easily extensible.
   (3) The code already existed. :-)
 * Stasis message types now have a message formatter that converts their payload to an ast_event object.
 * Stasis message forwarders now handle forwarding to themselves. Previously this would result in an infinite recursive call. Now, this simply creates a new forwarding object with no forwards set up (as it is the thing it is forwarding to). This is advantageous for res_corosync, as returning NULL would also imply an unrecoverable error. Returning a subscription in this case allows for easier handling of message types that are published directly to an aggregate topic that has forwarders.


Diffs
-----

  /branches/12/res/res_corosync.c 413035 
  /branches/12/main/stasis_message.c 413035 
  /branches/12/main/stasis.c 413035 
  /branches/12/main/event.c 413035 
  /branches/12/main/devicestate.c 413035 
  /branches/12/main/app.c 413035 
  /branches/12/include/asterisk/stasis.h 413035 
  /branches/12/include/asterisk/event_defs.h 413035 
  /branches/12/include/asterisk/event.h 413035 
  /branches/12/include/asterisk/devicestate.h 413035 

Diff: https://reviewboard.asterisk.org/r/3486/diff/


Testing
-------

Verified the following between a cluster with two Asterisk 12 systems and a cluster with an Asterisk 12 system and an Asterisk 11 system:
 * Pinging back and forth
 * MWI changes (publish and subscribe)
 * Device state changes (publish and subscribe)


Thanks,

Matt Jordan

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


More information about the asterisk-dev mailing list