asterisk

Commit Graph

Author	SHA1	Message	Date
David M. Lee	f29d969a79	Stasis: address refcount races; implementation comments Change r395954 reordered some stasis object destruction, which should have been fine. Unfortunately, it caused some hard to reproduce issues related to objects being accessed after they had been destroyed. The patch in r396329 fixed the destruction order problem; this patch addresses the underlying issue. A few other stasis-related fixes were also added. * Add ref-bumps around areas where objects may get transitively destroyed. (For example, where we lock a topic, unref a subscription, which unrefs the topic, which explodes the topic when we try to unlock it.) * Wrote an extensive doxygen page about Stasis implementation, relationships between objects, lifecycles of objects, how the refcounting works, etc. Many other comments were added, corrected, or cleaned up. * Added an assert to the topic dtor to catch extra ref decrements. * Fixed type used after destruction errors for graceful shutdown in stasis_channels.c. * I added two unit tests in an attempt to catch destruction order issues. Since the underlying cause is a race condition, though, the tests rarely failed even when the code was wrong. * Fixed a leak in stasis_cache_pattern.c. (closes issue ASTERISK-22243) Review: https://reviewboard.asterisk.org/r/2746/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396842 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	1d57078837	Fix stasis/core unit test. Should have had the CR/LF. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396480 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	154f45dd02	Add missing CR/LF to FakeMI stasis test AMI event. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396463 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	b97d318b7b	Tweak caching topics to fix CEL tests The Stasis changes in r395954 had an unanticipated side effect: messages published directly to an _all topic does not get forwarded to the corresponding caching topic. This patch fixes that by changing how caching topics forward messages, and how the caching pattern forwards are setup. For the caching pattern, the all_topic is forwarded to the all_topic_cached. This forwards messages published directly to the all_topic to all_topic_cached. In order to avoid duplicate messages on all_topic_cached, caching topics were changed to no longer forward uncached messages. Subscribers to an individual caching topic should only expect to receive cache updates, and subscription change messages. Since individual caching topics are new, this shouldn't be a problem. There are a few minor changes to the pre-cache split behavior. * For topics changed to use the caching pattern, the all_topic_cached will forward snapshots in addition to cache updates. Since subscribers by design ignore unexpected messages, this should be fine. * Caching topics that don't use the caching pattern no longer forward non-cache updates. This makes no difference for the current caching topics. * mwi_topic_cached, channel_by_name_topic and presence_state_topic_cached have no subscribers * device_state_topic_cached's only subscriber only processes cache udpates (issue ASTERISK-22243) Review: https://reviewboard.asterisk.org/r/2738 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396329 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	e1b959ccbb	Split caching out from the stasis_caching_topic. In working with res_stasis, I discovered a significant limitation to the current structure of stasis_caching_topics: you cannot subscribe to cache updates for a single channel/bridge/endpoint/etc. To address this, this patch splits the cache away from the stasis_caching_topic, making it a first class object. The stasis_cache object is shared amongst individual stasis_caching_topics that are created per channel/endpoint/etc. These are still forwarded to global whatever_all_cached topics, so their use from most of the code does not change. In making these changes, I noticed that we frequently used a similar pattern for bridges, endpoints and channels: single_topic ----------------> all_topic ^ \| single_topic_cached ----+----> all_topic_cached \| +----> cache This pattern was extracted as the 'Stasis Caching Pattern', defined in stasis_caching_pattern.h. This avoids a lot of duplicate code between the different domain objects. Since the cache is now disassociated from its upstream caching topics, this also necessitated a change to how the 'guaranteed' flag worked for retrieving from a cache. The code for handling the caching guarantee was extracted into a 'stasis_topic_wait' function, which works for any stasis_topic. (closes issue ASTERISK-22002) Review: https://reviewboard.asterisk.org/r/2672/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395954 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	fec667646f	Fix bridge/channel AMI event ordering issues The stasis_cache_update messages are somewhat cumbersome to handle with the stasis_message_router. Since all updates have the same message type, they are normally handled with the same route. Since caching itself is a first class component of stasis-core, it makes sense for the router to handle the cache update messages itself. This patch adds stasis_message_router_add_cache_update() and stasis_message_router_remove_cache_update() to handle the routing of stasis_cache_update messages. This patch also corrects an issue with manager_{bridging,channels}.c, where events might be reordered. The reordering occurs because the components use different message routers, which they needed because they both needed to route cache update messages. They now both use manager's router, and add cache routes for just the cache updates they are interested in. (closes issue ASTERISK-22038) Review: https://reviewboard.asterisk.org/r/2677/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395118 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	12 years ago
Kinsey Moore	759a7e4a30	Rework stasis cache clear events Stasis cache clear message payloads now consist of a stasis_message representative of the message to be cleared from the cache. This allows multiple parallel caches to coexist and be cleared properly by the same cache clear message even when keyed on different fields. This change fixes a bug where multiple cache clears could be posted for channels. The cache clear is now produced in the destructor instead of ast_hangup. Additionally, dummy channels are no longer capable of producing channel snapshots. Review: https://reviewboard.asterisk.org/r/2596 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390830 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	1c21b8575b	This patch adds a RESTful HTTP interface to Asterisk. The API itself is documented using Swagger, a lightweight mechanism for documenting RESTful API's using JSON. This allows us to use swagger-ui to provide executable documentation for the API, generate client bindings in different languages, and generate a lot of the boilerplate code for implementing the RESTful bindings. The API docs live in the rest-api/ directory. The RESTful bindings are generated from the Swagger API docs using a set of Mustache templates. The code generator is written in Python, and uses Pystache. Pystache has no dependencies, and be installed easily using pip. Code generation code lives in rest-api-templates/. The generated code reduces a lot of boilerplate when it comes to handling HTTP requests. It also helps us have greater consistency in the REST API. (closes issue ASTERISK-20891) Review: https://reviewboard.asterisk.org/r/2376/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386232 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	b23e8e1950	stasis: Fixed message ordering issues when forwarding This patch fixes an issue of message ordering that occurs when multiple topics are forwarded to an aggregator topic (such as ast_channel_topic_all()). It is (very reasonably) expected that the rules governing message dispatch order still apply, so long as the messages start from the same thread, and are received by the same subscription. Because the existing code had an additional layer of dispatching via the Stasis thread pool for forwards, those promises couldn't be kept. Forwarding subscriptions no longer have their own mailbox, and now dispatch directly from the forwarding topic's stasis_publish() call. This means that the topic's lock is held for the duration of not only a message's dispatch, but the dispatch of all the forwards. This shouldn't be a problem right now, but if an aggregator topic had many subscribers, it could become a problem. But I figure we can write more clever code when the time comes, if necessary. Review: https://reviewboard.asterisk.org/r/2419/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384413 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	71206544a7	Break the world. Stasis message type accessors should now all be named correctly. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384261 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 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	12 years ago
Kinsey Moore	ccb5526508	Take advantage of the fact that stasis_unsubscribe now returns NULL git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383169 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	c6b06e40dc	Add message dump capability to stasis cache layer The cache dump mechanism allows the developer to retreive multiple items of a given type (or of all types) from the cache residing in a stasis caching topic in addition to the existing single-item cache retreival mechanism. This also adds to the caching unit tests to ensure that the new cache dump mechanism is functioning properly. Review: https://reviewboard.asterisk.org/r/2367/ (issue ASTERISK-21097) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382705 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 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	12 years ago

15 Commits (dbec6e92d1a19e8537ab5bf7545e287ca5339df1)