asterisk

Commit Graph

Author	SHA1	Message	Date
Richard Mudgett	ac18bb23a9	stasis: No need to keep a stasis type ref in a stasis msg or cache object. Stasis message types are global ao2 objects and we make stasis messages and cache entries hold references to them. Since there are currently situations where cache objects are never deleted, the reference count on the types can exceed 100000 and generate a FRACK assertion message. The stasis message cache could conceivably also have that many messages legitimately on large systems. The only down side to not holding the message type ref in the stasis message is it only makes a crash either at shutdown or when manually unloading a busy module slightly more likely. However, this is more exposing a pre-existing stasis shutdown ordering issue than a problem with not holding a message type ref in stasis messages. * Made stasis messages and cache entries no longer hold a ref to the message type. Change-Id: Ibaa28efa8d8ad3836f0c65957192424c7f561707	7 years ago
Richard Mudgett	2f84ff9728	stasis_message.c: Don't create immutable stasis objects with locks. * Create the stasis message object without a lock as it is immutable. * Create the stasis message type object without a lock as it is immutable. * Creating the stasis message type could crash if the passed in type name is NULL and REF_DEBUG is enabled. Added missing NULL check when passing the ao2 object tag string. Change-Id: I28763c58bb9f0b427c11971d0103bf94055e7b32	7 years ago
Joshua Colp	856b6d1954	stasis: Reduce calculation of stasis message type hash. When the stasis cache is used a hash is calculated for retrieving or inserting messages. This change calculates a hash when the message type is initialized that is then used each time needed. This ensures that the hash is calculated only once for the message type. Change-Id: I4fe6bfdafb55bf5c322dd313fbd8c32cce73ef37	7 years ago
Richard Mudgett	ba63aa7c9e	Manager: Short circuit AMI message processing. Improve AMI message processing performance if there are no consumers listening for the messages. We now skip creating the AMI event message text strings. Change-Id: I7b22fc5ec4e500d00635c1a467aa8ea68a1bb2b3	10 years ago
Kinsey Moore	f1036f40dc	Stasis: Allow message types to be blocked This introduces stasis.conf and a mechanism to prevent certain message types from being published. Internally, this works by preventing the chosen message types from being created which ensures that those message types can never be published. This patch also adjusts message publishers such that message payloads are not created if the related message type is not available. ASTERISK-23943 #close Review: https://reviewboard.asterisk.org/r/3823/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420124 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Corey Farrell	fd7814ddb5	stasis: use ao2_t_alloc for certain object allocators Add tags to stasis objects using the name. This makes it easier to track the source of certain stasis ref leaks. Review: https://reviewboard.asterisk.org/r/3821/ ........ Merged revisions 418996 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418997 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	9cee08f502	res_corosync: Update module to work with Stasis (and compile) 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 in this patch were pulled from Asterisk 11. Previously, we had hoped that this information would live in res_corosync; however, the approach in this patch 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. Review: https://reviewboard.asterisk.org/r/3486/ ASTERISK-22912 #close ASTERISK-22372 #close ........ Merged revisions 414330 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414331 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	4ad1245cb5	stasis cache: Enhance to keep track of an item from different entities. A stasis cache entry now contains more than a single message/snapshot. It contains messages/snapshots for the local entity as well as any remote entities that post to the cached item. In addition callbacks can be supplied when the cache is created to compute and post the aggregate message/snapshot representing all entities stored in the cache entry. * All stasis messages now have an eid to indicate what entity posted it. * The stasis cache enhancements allow device state to cache and aggregate the device states from local and remote entities in a single operation. The cached aggregate device state is available immediately after it is posted to the stasis bus. This improves performance by eliminating a cache dump and associated ao2 container traversals to calculate the aggregate state. (closes issue ASTERISK-23204) Reported by: Mark Michelson Review: https://reviewboard.asterisk.org/r/3281/ ........ Merged revisions 410184 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410185 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	d9015a5356	ARI: Don't leak implementation details This change prevents channels used as implementation details from leaking out to ARI. It does this by preventing creation of JSON blobs of channel snapshots created from those channels and sanitizing JSON blobs of bridge snapshots as they are created. This introduces a framework for excluding information from output targeted at Stasis applications on a consumer-by-consumer basis using channel sanitization callbacks which could be extended to bridges or endpoints if necessary. This prevents unhelpful error messages from being generated by ast_json_pack. This also corrects a bug where BridgeCreated events would not be created. (closes issue ASTERISK-22744) Review: https://reviewboard.asterisk.org/r/2987/ Reported by: David M. Lee ........ Merged revisions 403069 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403070 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	dbdb2b1b3a	Add vtable and methods for to_json and to_ami for Stasis messages When a Stasis message type is defined in a loadable module, handling those messages for AMI and res_stasis events can be cumbersome. This patch adds a vtable to stasis_message_type, with to_ami and to_json virtual functions. These allow messages to be handled abstractly without putting module-specific code in core. As an example, the VarSet AMI event was refactored to use the to_ami virtual function. (closes issue ASTERISK-21817) Review: https://reviewboard.asterisk.org/r/2579/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391403 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	49e3489cac	A simplistic router for stasis_message's. Often times, when subscribing to a topic, one wants to handle different message types differently. While one could cascade if/else statements through the subscription handler, it is much cleaner to specify a different callback for each message type. The stasis_message_router is here to help! A stasis_message_router is constructed for a particular stasis_topic, which is subscribes to. Call stasis_message_router_unsubscribe() to cancel that subscription. Once constructed, routes can be added using stasis_message_router_add() (or stasis_message_router_set_default() for any messages not handled by other routes). There may be only one route per stasis_message_type. The route's callback is invoked just as if it were a callback for a subscription; but it only gets called for messages of the specified type. (issue ASTERISK-20887) Review: https://reviewboard.asterisk.org/r/2390/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383242 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	4edd8be35c	This patch adds a new message bus API to Asterisk. For the initial use of this bus, I took some work kmoore did creating channel snapshots. So rather than create AMI events directly in the channel code, this patch generates Stasis events, which manager.c uses to then publish the AMI event. This message bus provides a generic publish/subscribe mechanism within Asterisk. This message bus is: - Loosely coupled; new message types can be added in seperate modules. - Easy to use; publishing and subscribing are straightforward operations. In addition to basic publish/subscribe, the patch also provides mechanisms for message forwarding, and for message caching. (issue ASTERISK-20887) (closes issue ASTERISK-20959) Review: https://reviewboard.asterisk.org/r/2339/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382685 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago

12 Commits (ec52409a530d9cdbee2e6524d460ab8b27f25d24)