6 Commits (1974ebe10956a5dfaeb204c6fa5894cc2d58f53c)

Author	SHA1	Message	Date
Alexander Traud	4b6c72572c	progdocs: Fix Doxygen left-overs. ... Change-Id: I5b5cf9c9cbbe00ba8b379a8d162ac67445d39016	5 years ago
Joshua Colp	3077ad0c24	stasis: Add internal filtering of messages. ... This change adds the ability for subscriptions to indicate which message types they are interested in accepting. By doing so the filtering is done before being dispatched to the subscriber, reducing the amount of work that has to be done. This is optional and if a subscriber does not add message types they wish to accept and set the subscription to selective filtering the previous behavior is preserved and they receive all messages. There is also the ability to explicitly force the reception of all messages for cases such as AMI or ARI where a large number of messages are expected that are then generically converted into a different format. ASTERISK-28103 Change-Id: I99bee23895baa0a117985d51683f7963b77aa190	8 years ago
George Joseph	22db16fa81	endpoint/stasis: Eliminate duplicate events on endpoint status change ... When an endpoint is created, its messages are forwarded to both the tech endpoint topic and the all endpoints topic. This is done so that various parties interested in endpoint messages can subscribe to just the tech endpoint and receive all messages associated with that particular technology, as opposed to subscribing to the all endpoints topic. Unfortunately, when the tech endpoint is created, it also forwards all of its messages to the all topic. This results in duplicate messages whenever an endpoint publishes its messages. This patch resolves the duplicate message issue by creating a new function for Stasis caching topics, stasis_cp_sink_create. In most respects, this acts as a normal caching topic, save that it no longer forwards messages it receives to the all endpoints topic. This allows it to act as an aggregation "sink", while preserving the necessary caching behaviour. ASTERISK-25137 #close Reported-by: Vitezslav Novy ASTERISK-25116 #close Reported-by: George Joseph <george.joseph@fairview5.com> Tested-by: George Joseph <george.joseph@fairview5.com> Change-Id: Ie47784adfb973ab0063e59fc18f390d7dd26d17b	11 years ago
George Joseph	82716410a4	Revert "endpoint/stasis: Eliminate duplicate events on endpoint status change" ... This reverts commit 6fca75bb62. Change-Id: Ifee026cc63e22c5ac5717c37867a9f036373ae5a	11 years ago
George Joseph	6fca75bb62	endpoint/stasis: Eliminate duplicate events on endpoint status change ... When an endpoint was created, it's messages were being forwarded to both the tech endpoint topic and the all endpoints topic. Since the tech topic was also forwarded to all, this was resulting in duplicate messages whenever an endpoint published. This patch causes the endpoint to only forward to the tech topic and lets the tech topic forward to all. To accomplish this, the existing stasis_cp_single_create function (which both creates and forwards) was cloned and split into 2 functions, one that creates the topic and one that sets up the forwarding. This allows endpoint_internal_create to create the topic from the endpoint_all cache without forwarding it there, then allows it to do the forward to the tech's topic. ASTERISK-25137 #close Reported-by: Vitezslav Novy ASTERISK-25116 #close Reported-by: George Joseph <george.joseph@fairview5.com> Tested-by: George Joseph <george.joseph@fairview5.com> Change-Id: I26d7d4926a0861748fd3bdffe316b75b549a801c	11 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	13 years ago