[asterisk-dev] [Code Review] 2672: Split caching out from the stasis_caching_topic
svnbot
reviewboard at asterisk.org
Thu Aug 1 08:49:39 CDT 2013
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2672/
-----------------------------------------------------------
(Updated Aug. 1, 2013, 8:49 a.m.)
Status
------
This change has been marked as submitted.
Review request for Asterisk Developers.
Changes
-------
Committed in revision 395954
Bugs: ASTERISK-22002
https://issues.asterisk.org/jira/browse/ASTERISK-22002
Repository: Asterisk
Description
-------
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.
Diffs
-----
/trunk/apps/app_meetme.c 395719
/trunk/apps/app_voicemail.c 395719
/trunk/apps/confbridge/confbridge_manager.c 395719
/trunk/channels/chan_dahdi.c 395719
/trunk/channels/chan_gulp.c 395719
/trunk/channels/chan_iax2.c 395719
/trunk/channels/chan_mgcp.c 395719
/trunk/channels/chan_sip.c 395719
/trunk/channels/chan_unistim.c 395719
/trunk/channels/sig_pri.c 395719
/trunk/include/asterisk/app.h 395719
/trunk/include/asterisk/bridge.h 395719
/trunk/include/asterisk/channel.h 395719
/trunk/include/asterisk/channel_internal.h 395719
/trunk/include/asterisk/devicestate.h 395719
/trunk/include/asterisk/presencestate.h 395719
/trunk/include/asterisk/stasis.h 395719
/trunk/include/asterisk/stasis_bridges.h 395719
/trunk/include/asterisk/stasis_cache_pattern.h PRE-CREATION
/trunk/include/asterisk/stasis_channels.h 395719
/trunk/include/asterisk/stasis_endpoints.h 395719
/trunk/main/app.c 395719
/trunk/main/bridge.c 395719
/trunk/main/cdr.c 395719
/trunk/main/cel.c 395719
/trunk/main/channel_internal_api.c 395719
/trunk/main/cli.c 395719
/trunk/main/devicestate.c 395719
/trunk/main/endpoints.c 395719
/trunk/main/manager.c 395719
/trunk/main/manager_bridges.c 395719
/trunk/main/manager_channels.c 395719
/trunk/main/manager_endpoints.c 395719
/trunk/main/pbx.c 395719
/trunk/main/presencestate.c 395719
/trunk/main/stasis.c 395719
/trunk/main/stasis_bridges.c 395719
/trunk/main/stasis_cache.c 395719
/trunk/main/stasis_cache_pattern.c PRE-CREATION
/trunk/main/stasis_channels.c 395719
/trunk/main/stasis_endpoints.c 395719
/trunk/main/stasis_wait.c PRE-CREATION
/trunk/res/ari/resource_bridges.c 395719
/trunk/res/ari/resource_channels.c 395719
/trunk/res/ari/resource_endpoints.c 395719
/trunk/res/res_agi.c 395719
/trunk/res/res_chan_stats.c 395719
/trunk/res/res_jabber.c 395719
/trunk/res/res_sip_mwi.c 395719
/trunk/res/res_stasis.c 395719
/trunk/res/res_xmpp.c 395719
/trunk/res/stasis/control.c 395719
/trunk/tests/test_cel.c 395719
/trunk/tests/test_devicestate.c 395719
/trunk/tests/test_stasis.c 395719
/trunk/tests/test_stasis_endpoints.c 395719
Diff: https://reviewboard.asterisk.org/r/2672/diff/
Testing
-------
Tests pass.
Thanks,
David Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130801/8d897e52/attachment-0001.htm>
More information about the asterisk-dev
mailing list