asterisk/tests/test_stasis_endpoints.c

304 lines
9.3 KiB
C
Raw Normal View History

Initial support for endpoints. An endpoint is an external device/system that may offer/accept channels to/from Asterisk. While this is a very useful concept for end users, it is surprisingly not a core concept within Asterisk itself. This patch defines ast_endpoint as a separate object, which channel drivers may use to expose their concept of an endpoint. As the channel driver creates channels, it can use ast_endpoint_add_channel() to associate channels to the endpoint. This updated the endpoint appropriately, and forwards all of the channel's events to the endpoint's topic. In order to avoid excessive locking on the endpoint object itself, the mutable state is not accessible via getters. Instead, you can create a snapshot using ast_endpoint_snapshot_create() to get a consistent snapshot of the internal state. This patch also includes a set of topics and messages associated with endpoints, and implementations of the endpoint-related RESTful API. chan_sip was updated to create endpoints with SIP peers, but the state of the endpoints is not updated with the state of the peer. Along for the ride in this patch is a Stasis test API. This is a stasis_message_sink object, which can be subscribed to a Stasis topic. It has functions for blocking while waiting for conditions in the message sink to be fulfilled. (closes issue ASTERISK-21421) Review: https://reviewboard.asterisk.org/r/2492/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 13:39:08 +00:00
/*
* Asterisk -- An open source telephony toolkit.
*
* Copyright (C) 2013, Digium, Inc.
*
* David M. Lee, II <dlee@digium.com>
*
* See http://www.asterisk.org for more information about
* the Asterisk project. Please do not directly contact
* any of the maintainers of this project for assistance;
* the project provides a web site, mailing lists and IRC
* channels for your use.
*
* This program is free software, distributed under the terms of
* the GNU General Public License Version 2. See the LICENSE file
* at the top of the source tree.
*/
/*!
* \file \brief Test endpoints.
*
* \author\verbatim David M. Lee, II <dlee@digium.com> \endverbatim
*
* \ingroup tests
*/
/*** MODULEINFO
<depend>TEST_FRAMEWORK</depend>
<depend>res_stasis_test</depend>
<support_level>core</support_level>
***/
#include "asterisk.h"
ASTERISK_FILE_VERSION(__FILE__, "$Revision$")
#include "asterisk/astobj2.h"
#include "asterisk/channel.h"
#include "asterisk/endpoints.h"
#include "asterisk/module.h"
#include "asterisk/stasis_channels.h"
#include "asterisk/stasis_endpoints.h"
#include "asterisk/stasis_test.h"
#include "asterisk/test.h"
static const char *test_category = "/stasis/endpoints/";
/*! \brief Message matcher looking for cache update messages */
static int cache_update(struct stasis_message *msg, const void *data) {
struct stasis_cache_update *update;
struct ast_endpoint_snapshot *snapshot;
const char *name = data;
if (stasis_cache_update_type() != stasis_message_type(msg)) {
return 0;
}
update = stasis_message_data(msg);
if (ast_endpoint_snapshot_type() != update->type) {
return 0;
}
snapshot = stasis_message_data(update->old_snapshot);
if (!snapshot) {
snapshot = stasis_message_data(update->new_snapshot);
}
return 0 == strcmp(name, snapshot->resource);
}
AST_TEST_DEFINE(state_changes)
{
RAII_VAR(struct ast_endpoint *, uut, NULL, ast_endpoint_shutdown);
RAII_VAR(struct ast_channel *, chan, NULL, ast_hangup);
Initial support for endpoints. An endpoint is an external device/system that may offer/accept channels to/from Asterisk. While this is a very useful concept for end users, it is surprisingly not a core concept within Asterisk itself. This patch defines ast_endpoint as a separate object, which channel drivers may use to expose their concept of an endpoint. As the channel driver creates channels, it can use ast_endpoint_add_channel() to associate channels to the endpoint. This updated the endpoint appropriately, and forwards all of the channel's events to the endpoint's topic. In order to avoid excessive locking on the endpoint object itself, the mutable state is not accessible via getters. Instead, you can create a snapshot using ast_endpoint_snapshot_create() to get a consistent snapshot of the internal state. This patch also includes a set of topics and messages associated with endpoints, and implementations of the endpoint-related RESTful API. chan_sip was updated to create endpoints with SIP peers, but the state of the endpoints is not updated with the state of the peer. Along for the ride in this patch is a Stasis test API. This is a stasis_message_sink object, which can be subscribed to a Stasis topic. It has functions for blocking while waiting for conditions in the message sink to be fulfilled. (closes issue ASTERISK-21421) Review: https://reviewboard.asterisk.org/r/2492/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 13:39:08 +00:00
RAII_VAR(struct stasis_message_sink *, sink, NULL, ao2_cleanup);
RAII_VAR(struct stasis_subscription *, sub, NULL, stasis_unsubscribe);
struct stasis_message *msg;
struct stasis_message_type *type;
struct ast_endpoint_snapshot *actual_snapshot;
int actual_count;
switch (cmd) {
case TEST_INIT:
info->name = __func__;
info->category = test_category;
info->summary = "Test endpoint updates as its state changes";
info->description =
"Test endpoint updates as its state changes";
return AST_TEST_NOT_RUN;
case TEST_EXECUTE:
break;
}
uut = ast_endpoint_create("TEST", __func__);
ast_test_validate(test, NULL != uut);
sink = stasis_message_sink_create();
ast_test_validate(test, NULL != sink);
sub = stasis_subscribe(ast_endpoint_topic(uut),
stasis_message_sink_cb(), sink);
ast_test_validate(test, NULL != sub);
ast_endpoint_set_state(uut, AST_ENDPOINT_OFFLINE);
actual_count = stasis_message_sink_wait_for_count(sink, 1,
STASIS_SINK_DEFAULT_WAIT);
ast_test_validate(test, 1 == actual_count);
Initial support for endpoints. An endpoint is an external device/system that may offer/accept channels to/from Asterisk. While this is a very useful concept for end users, it is surprisingly not a core concept within Asterisk itself. This patch defines ast_endpoint as a separate object, which channel drivers may use to expose their concept of an endpoint. As the channel driver creates channels, it can use ast_endpoint_add_channel() to associate channels to the endpoint. This updated the endpoint appropriately, and forwards all of the channel's events to the endpoint's topic. In order to avoid excessive locking on the endpoint object itself, the mutable state is not accessible via getters. Instead, you can create a snapshot using ast_endpoint_snapshot_create() to get a consistent snapshot of the internal state. This patch also includes a set of topics and messages associated with endpoints, and implementations of the endpoint-related RESTful API. chan_sip was updated to create endpoints with SIP peers, but the state of the endpoints is not updated with the state of the peer. Along for the ride in this patch is a Stasis test API. This is a stasis_message_sink object, which can be subscribed to a Stasis topic. It has functions for blocking while waiting for conditions in the message sink to be fulfilled. (closes issue ASTERISK-21421) Review: https://reviewboard.asterisk.org/r/2492/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 13:39:08 +00:00
msg = sink->messages[0];
type = stasis_message_type(msg);
ast_test_validate(test, ast_endpoint_snapshot_type() == type);
actual_snapshot = stasis_message_data(msg);
ast_test_validate(test, AST_ENDPOINT_OFFLINE == actual_snapshot->state);
ast_endpoint_set_max_channels(uut, 8675309);
actual_count = stasis_message_sink_wait_for_count(sink, 2,
STASIS_SINK_DEFAULT_WAIT);
ast_test_validate(test, 2 == actual_count);
Initial support for endpoints. An endpoint is an external device/system that may offer/accept channels to/from Asterisk. While this is a very useful concept for end users, it is surprisingly not a core concept within Asterisk itself. This patch defines ast_endpoint as a separate object, which channel drivers may use to expose their concept of an endpoint. As the channel driver creates channels, it can use ast_endpoint_add_channel() to associate channels to the endpoint. This updated the endpoint appropriately, and forwards all of the channel's events to the endpoint's topic. In order to avoid excessive locking on the endpoint object itself, the mutable state is not accessible via getters. Instead, you can create a snapshot using ast_endpoint_snapshot_create() to get a consistent snapshot of the internal state. This patch also includes a set of topics and messages associated with endpoints, and implementations of the endpoint-related RESTful API. chan_sip was updated to create endpoints with SIP peers, but the state of the endpoints is not updated with the state of the peer. Along for the ride in this patch is a Stasis test API. This is a stasis_message_sink object, which can be subscribed to a Stasis topic. It has functions for blocking while waiting for conditions in the message sink to be fulfilled. (closes issue ASTERISK-21421) Review: https://reviewboard.asterisk.org/r/2492/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 13:39:08 +00:00
msg = sink->messages[1];
type = stasis_message_type(msg);
ast_test_validate(test, ast_endpoint_snapshot_type() == type);
actual_snapshot = stasis_message_data(msg);
ast_test_validate(test, 8675309 == actual_snapshot->max_channels);
return AST_TEST_PASS;
}
AST_TEST_DEFINE(cache_clear)
{
RAII_VAR(struct ast_endpoint *, uut, NULL, ast_endpoint_shutdown);
RAII_VAR(struct ast_channel *, chan, NULL, ast_hangup);
Initial support for endpoints. An endpoint is an external device/system that may offer/accept channels to/from Asterisk. While this is a very useful concept for end users, it is surprisingly not a core concept within Asterisk itself. This patch defines ast_endpoint as a separate object, which channel drivers may use to expose their concept of an endpoint. As the channel driver creates channels, it can use ast_endpoint_add_channel() to associate channels to the endpoint. This updated the endpoint appropriately, and forwards all of the channel's events to the endpoint's topic. In order to avoid excessive locking on the endpoint object itself, the mutable state is not accessible via getters. Instead, you can create a snapshot using ast_endpoint_snapshot_create() to get a consistent snapshot of the internal state. This patch also includes a set of topics and messages associated with endpoints, and implementations of the endpoint-related RESTful API. chan_sip was updated to create endpoints with SIP peers, but the state of the endpoints is not updated with the state of the peer. Along for the ride in this patch is a Stasis test API. This is a stasis_message_sink object, which can be subscribed to a Stasis topic. It has functions for blocking while waiting for conditions in the message sink to be fulfilled. (closes issue ASTERISK-21421) Review: https://reviewboard.asterisk.org/r/2492/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 13:39:08 +00:00
RAII_VAR(struct stasis_message_sink *, sink, NULL, ao2_cleanup);
RAII_VAR(struct stasis_subscription *, sub, NULL, stasis_unsubscribe);
struct stasis_message *msg;
struct stasis_message_type *type;
struct ast_endpoint_snapshot *actual_snapshot;
struct stasis_cache_update *update;
int message_index;
switch (cmd) {
case TEST_INIT:
info->name = __func__;
info->category = test_category;
info->summary = "Test endpoint state change messages";
info->description = "Test endpoint state change messages";
return AST_TEST_NOT_RUN;
case TEST_EXECUTE:
break;
}
/* Subscribe to the cache topic */
sink = stasis_message_sink_create();
ast_test_validate(test, NULL != sink);
sub = stasis_subscribe(
ast_endpoint_topic_all_cached(),
Initial support for endpoints. An endpoint is an external device/system that may offer/accept channels to/from Asterisk. While this is a very useful concept for end users, it is surprisingly not a core concept within Asterisk itself. This patch defines ast_endpoint as a separate object, which channel drivers may use to expose their concept of an endpoint. As the channel driver creates channels, it can use ast_endpoint_add_channel() to associate channels to the endpoint. This updated the endpoint appropriately, and forwards all of the channel's events to the endpoint's topic. In order to avoid excessive locking on the endpoint object itself, the mutable state is not accessible via getters. Instead, you can create a snapshot using ast_endpoint_snapshot_create() to get a consistent snapshot of the internal state. This patch also includes a set of topics and messages associated with endpoints, and implementations of the endpoint-related RESTful API. chan_sip was updated to create endpoints with SIP peers, but the state of the endpoints is not updated with the state of the peer. Along for the ride in this patch is a Stasis test API. This is a stasis_message_sink object, which can be subscribed to a Stasis topic. It has functions for blocking while waiting for conditions in the message sink to be fulfilled. (closes issue ASTERISK-21421) Review: https://reviewboard.asterisk.org/r/2492/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 13:39:08 +00:00
stasis_message_sink_cb(), sink);
ast_test_validate(test, NULL != sub);
uut = ast_endpoint_create("TEST", __func__);
ast_test_validate(test, NULL != uut);
/* Since the cache topic is a singleton (ew), it may have messages from
* elsewheres that it's processing, or maybe even some final messages
* from the prior test. We've got to wait_for our specific message,
* instead of wait_for_count.
*/
message_index = stasis_message_sink_wait_for(sink, 0,
cache_update, __func__, STASIS_SINK_DEFAULT_WAIT);
ast_test_validate(test, 0 <= message_index);
/* First message should be a cache creation entry for our endpont */
msg = sink->messages[message_index];
type = stasis_message_type(msg);
ast_test_validate(test, stasis_cache_update_type() == type);
update = stasis_message_data(msg);
ast_test_validate(test, ast_endpoint_snapshot_type() == update->type);
ast_test_validate(test, NULL == update->old_snapshot);
actual_snapshot = stasis_message_data(update->new_snapshot);
ast_test_validate(test, 0 == strcmp("TEST", actual_snapshot->tech));
ast_test_validate(test,
0 == strcmp(__func__, actual_snapshot->resource));
ast_endpoint_shutdown(uut);
uut = NULL;
message_index = stasis_message_sink_wait_for(sink, message_index + 1,
cache_update, __func__, STASIS_SINK_DEFAULT_WAIT);
ast_test_validate(test, 0 <= message_index);
/* Now we should have a cache removal entry */
msg = sink->messages[message_index];
type = stasis_message_type(msg);
ast_test_validate(test, stasis_cache_update_type() == type);
update = stasis_message_data(msg);
ast_test_validate(test, ast_endpoint_snapshot_type() == update->type);
actual_snapshot = stasis_message_data(update->old_snapshot);
ast_test_validate(test, 0 == strcmp("TEST", actual_snapshot->tech));
ast_test_validate(test,
0 == strcmp(__func__, actual_snapshot->resource));
ast_test_validate(test, NULL == update->new_snapshot);
return AST_TEST_PASS;
}
AST_TEST_DEFINE(channel_messages)
{
RAII_VAR(struct ast_endpoint *, uut, NULL, ast_endpoint_shutdown);
RAII_VAR(struct ast_channel *, chan, NULL, ast_hangup);
Initial support for endpoints. An endpoint is an external device/system that may offer/accept channels to/from Asterisk. While this is a very useful concept for end users, it is surprisingly not a core concept within Asterisk itself. This patch defines ast_endpoint as a separate object, which channel drivers may use to expose their concept of an endpoint. As the channel driver creates channels, it can use ast_endpoint_add_channel() to associate channels to the endpoint. This updated the endpoint appropriately, and forwards all of the channel's events to the endpoint's topic. In order to avoid excessive locking on the endpoint object itself, the mutable state is not accessible via getters. Instead, you can create a snapshot using ast_endpoint_snapshot_create() to get a consistent snapshot of the internal state. This patch also includes a set of topics and messages associated with endpoints, and implementations of the endpoint-related RESTful API. chan_sip was updated to create endpoints with SIP peers, but the state of the endpoints is not updated with the state of the peer. Along for the ride in this patch is a Stasis test API. This is a stasis_message_sink object, which can be subscribed to a Stasis topic. It has functions for blocking while waiting for conditions in the message sink to be fulfilled. (closes issue ASTERISK-21421) Review: https://reviewboard.asterisk.org/r/2492/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 13:39:08 +00:00
RAII_VAR(struct stasis_message_sink *, sink, NULL, ao2_cleanup);
RAII_VAR(struct stasis_subscription *, sub, NULL, stasis_unsubscribe);
struct stasis_message *msg;
struct stasis_message_type *type;
struct ast_endpoint_snapshot *actual_snapshot;
int actual_count;
switch (cmd) {
case TEST_INIT:
info->name = __func__;
info->category = test_category;
info->summary = "Test channel messages on an endpoint topic";
info->description =
"Test channel messages on an endpoint topic";
return AST_TEST_NOT_RUN;
case TEST_EXECUTE:
break;
}
uut = ast_endpoint_create("TEST", __func__);
ast_test_validate(test, NULL != uut);
sink = stasis_message_sink_create();
ast_test_validate(test, NULL != sink);
sub = stasis_subscribe(ast_endpoint_topic(uut),
stasis_message_sink_cb(), sink);
ast_test_validate(test, NULL != sub);
chan = ast_channel_alloc(0, AST_STATE_DOWN, "100", __func__, "100",
"100", "default", NULL, 0, "TEST/test_res");
ast_test_validate(test, NULL != chan);
ast_endpoint_add_channel(uut, chan);
actual_count = stasis_message_sink_wait_for_count(sink, 2,
STASIS_SINK_DEFAULT_WAIT);
ast_test_validate(test, 2 == actual_count);
msg = sink->messages[0];
type = stasis_message_type(msg);
ast_test_validate(test, ast_channel_snapshot_type() == type);
msg = sink->messages[1];
type = stasis_message_type(msg);
ast_test_validate(test, ast_endpoint_snapshot_type() == type);
actual_snapshot = stasis_message_data(msg);
ast_test_validate(test, 1 == actual_snapshot->num_channels);
ast_hangup(chan);
Initial support for endpoints. An endpoint is an external device/system that may offer/accept channels to/from Asterisk. While this is a very useful concept for end users, it is surprisingly not a core concept within Asterisk itself. This patch defines ast_endpoint as a separate object, which channel drivers may use to expose their concept of an endpoint. As the channel driver creates channels, it can use ast_endpoint_add_channel() to associate channels to the endpoint. This updated the endpoint appropriately, and forwards all of the channel's events to the endpoint's topic. In order to avoid excessive locking on the endpoint object itself, the mutable state is not accessible via getters. Instead, you can create a snapshot using ast_endpoint_snapshot_create() to get a consistent snapshot of the internal state. This patch also includes a set of topics and messages associated with endpoints, and implementations of the endpoint-related RESTful API. chan_sip was updated to create endpoints with SIP peers, but the state of the endpoints is not updated with the state of the peer. Along for the ride in this patch is a Stasis test API. This is a stasis_message_sink object, which can be subscribed to a Stasis topic. It has functions for blocking while waiting for conditions in the message sink to be fulfilled. (closes issue ASTERISK-21421) Review: https://reviewboard.asterisk.org/r/2492/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 13:39:08 +00:00
chan = NULL;
actual_count = stasis_message_sink_wait_for_count(sink, 5,
STASIS_SINK_DEFAULT_WAIT);
ast_test_validate(test, 5 == actual_count);
msg = sink->messages[2];
type = stasis_message_type(msg);
ast_test_validate(test, ast_channel_snapshot_type() == type);
Multiple revisions 399887,400138,400178,400180-400181 ........ r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line Minor performance bump by not allocate manager variable struct if we don't need it ........ r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines Stasis performance improvements This patch addresses several performance problems that were found in the initial performance testing of Asterisk 12. The Stasis dispatch object was allocated as an AO2 object, even though it has a very confined lifecycle. This was replaced with a straight ast_malloc(). The Stasis message router was spending an inordinate amount of time searching hash tables. In this case, most of our routers had 6 or fewer routes in them to begin with. This was replaced with an array that's searched linearly for the route. We more heavily rely on AO2 objects in Asterisk 12, and the memset() in ao2_ref() actually became noticeable on the profile. This was #ifdef'ed to only run when AO2_DEBUG was enabled. After being misled by an erroneous comment in taskprocessor.c during profiling, the wrong comment was removed. Review: https://reviewboard.asterisk.org/r/2873/ ........ r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines Taskprocessor optimization; switch Stasis to use taskprocessors This patch optimizes taskprocessor to use a semaphore for signaling, which the OS can do a better job at managing contention and waiting that we can with a mutex and condition. The taskprocessor execution was also slightly optimized to reduce the number of locks taken. The only observable difference in the taskprocessor implementation is that when the final reference to the taskprocessor goes away, it will execute all tasks to completion instead of discarding the unexecuted tasks. For systems where unnamed semaphores are not supported, a really simple semaphore implementation is provided. (Which gives identical performance as the original taskprocessor implementation). The way we ended up implementing Stasis caused the threadpool to be a burden instead of a boost to performance. This was switched to just use taskprocessors directly for subscriptions. Review: https://reviewboard.asterisk.org/r/2881/ ........ r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines Optimize how Stasis forwards are dispatched This patch optimizes how forwards are dispatched in Stasis. Originally, forwards were dispatched as subscriptions that are invoked on the publishing thread. This did not account for the vast number of forwards we would end up having in the system, and the amount of work it would take to walk though the forward subscriptions. This patch modifies Stasis so that rather than walking the tree of forwards on every dispatch, when forwards and subscriptions are changed, the subscriber list for every topic in the tree is changed. This has a couple of benefits. First, this reduces the workload of dispatching messages. It also reduces contention when dispatching to different topics that happen to forward to the same aggregation topic (as happens with all of the channel, bridge and endpoint topics). Since forwards are no longer subscriptions, the bulk of this patch is simply changing stasis_subscription objects to stasis_forward objects (which, admittedly, I should have done in the first place.) Since this required me to yet again put in a growing array, I finally abstracted that out into a set of ast_vector macros in asterisk/vector.h. Review: https://reviewboard.asterisk.org/r/2883/ ........ r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines Remove dispatch object allocation from Stasis publishing While looking for areas for performance improvement, I realized that an unused feature in Stasis was negatively impacting performance. When a message is sent to a subscriber, a dispatch object is allocated for the dispatch, containing the topic the message was published to, the subscriber the message is being sent to, and the message itself. The topic is actually unused by any subscriber in Asterisk today. And the subscriber is associated with the taskprocessor the message is being dispatched to. First, this patch removes the unused topic parameter from Stasis subscription callbacks. Second, this patch introduces the concept of taskprocessor local data, data that may be set on a taskprocessor and provided along with the data pointer when a task is pushed using the ast_taskprocessor_push_local() call. This allows the task to have both data specific to that taskprocessor, in addition to data specific to that invocation. With those two changes, the dispatch object can be removed completely, and the message is simply refcounted and sent directly to the taskprocessor. Review: https://reviewboard.asterisk.org/r/2884/ ........ Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-09-30 18:55:27 +00:00
/* The ordering of the cache clear and endpoint snapshot are
* unspecified */
Initial support for endpoints. An endpoint is an external device/system that may offer/accept channels to/from Asterisk. While this is a very useful concept for end users, it is surprisingly not a core concept within Asterisk itself. This patch defines ast_endpoint as a separate object, which channel drivers may use to expose their concept of an endpoint. As the channel driver creates channels, it can use ast_endpoint_add_channel() to associate channels to the endpoint. This updated the endpoint appropriately, and forwards all of the channel's events to the endpoint's topic. In order to avoid excessive locking on the endpoint object itself, the mutable state is not accessible via getters. Instead, you can create a snapshot using ast_endpoint_snapshot_create() to get a consistent snapshot of the internal state. This patch also includes a set of topics and messages associated with endpoints, and implementations of the endpoint-related RESTful API. chan_sip was updated to create endpoints with SIP peers, but the state of the endpoints is not updated with the state of the peer. Along for the ride in this patch is a Stasis test API. This is a stasis_message_sink object, which can be subscribed to a Stasis topic. It has functions for blocking while waiting for conditions in the message sink to be fulfilled. (closes issue ASTERISK-21421) Review: https://reviewboard.asterisk.org/r/2492/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 13:39:08 +00:00
msg = sink->messages[3];
Multiple revisions 399887,400138,400178,400180-400181 ........ r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line Minor performance bump by not allocate manager variable struct if we don't need it ........ r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines Stasis performance improvements This patch addresses several performance problems that were found in the initial performance testing of Asterisk 12. The Stasis dispatch object was allocated as an AO2 object, even though it has a very confined lifecycle. This was replaced with a straight ast_malloc(). The Stasis message router was spending an inordinate amount of time searching hash tables. In this case, most of our routers had 6 or fewer routes in them to begin with. This was replaced with an array that's searched linearly for the route. We more heavily rely on AO2 objects in Asterisk 12, and the memset() in ao2_ref() actually became noticeable on the profile. This was #ifdef'ed to only run when AO2_DEBUG was enabled. After being misled by an erroneous comment in taskprocessor.c during profiling, the wrong comment was removed. Review: https://reviewboard.asterisk.org/r/2873/ ........ r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines Taskprocessor optimization; switch Stasis to use taskprocessors This patch optimizes taskprocessor to use a semaphore for signaling, which the OS can do a better job at managing contention and waiting that we can with a mutex and condition. The taskprocessor execution was also slightly optimized to reduce the number of locks taken. The only observable difference in the taskprocessor implementation is that when the final reference to the taskprocessor goes away, it will execute all tasks to completion instead of discarding the unexecuted tasks. For systems where unnamed semaphores are not supported, a really simple semaphore implementation is provided. (Which gives identical performance as the original taskprocessor implementation). The way we ended up implementing Stasis caused the threadpool to be a burden instead of a boost to performance. This was switched to just use taskprocessors directly for subscriptions. Review: https://reviewboard.asterisk.org/r/2881/ ........ r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines Optimize how Stasis forwards are dispatched This patch optimizes how forwards are dispatched in Stasis. Originally, forwards were dispatched as subscriptions that are invoked on the publishing thread. This did not account for the vast number of forwards we would end up having in the system, and the amount of work it would take to walk though the forward subscriptions. This patch modifies Stasis so that rather than walking the tree of forwards on every dispatch, when forwards and subscriptions are changed, the subscriber list for every topic in the tree is changed. This has a couple of benefits. First, this reduces the workload of dispatching messages. It also reduces contention when dispatching to different topics that happen to forward to the same aggregation topic (as happens with all of the channel, bridge and endpoint topics). Since forwards are no longer subscriptions, the bulk of this patch is simply changing stasis_subscription objects to stasis_forward objects (which, admittedly, I should have done in the first place.) Since this required me to yet again put in a growing array, I finally abstracted that out into a set of ast_vector macros in asterisk/vector.h. Review: https://reviewboard.asterisk.org/r/2883/ ........ r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines Remove dispatch object allocation from Stasis publishing While looking for areas for performance improvement, I realized that an unused feature in Stasis was negatively impacting performance. When a message is sent to a subscriber, a dispatch object is allocated for the dispatch, containing the topic the message was published to, the subscriber the message is being sent to, and the message itself. The topic is actually unused by any subscriber in Asterisk today. And the subscriber is associated with the taskprocessor the message is being dispatched to. First, this patch removes the unused topic parameter from Stasis subscription callbacks. Second, this patch introduces the concept of taskprocessor local data, data that may be set on a taskprocessor and provided along with the data pointer when a task is pushed using the ast_taskprocessor_push_local() call. This allows the task to have both data specific to that taskprocessor, in addition to data specific to that invocation. With those two changes, the dispatch object can be removed completely, and the message is simply refcounted and sent directly to the taskprocessor. Review: https://reviewboard.asterisk.org/r/2884/ ........ Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-09-30 18:55:27 +00:00
if (stasis_message_type(msg) == stasis_cache_clear_type()) {
/* Okay; the next message should be the endpoint snapshot */
msg = sink->messages[4];
}
Initial support for endpoints. An endpoint is an external device/system that may offer/accept channels to/from Asterisk. While this is a very useful concept for end users, it is surprisingly not a core concept within Asterisk itself. This patch defines ast_endpoint as a separate object, which channel drivers may use to expose their concept of an endpoint. As the channel driver creates channels, it can use ast_endpoint_add_channel() to associate channels to the endpoint. This updated the endpoint appropriately, and forwards all of the channel's events to the endpoint's topic. In order to avoid excessive locking on the endpoint object itself, the mutable state is not accessible via getters. Instead, you can create a snapshot using ast_endpoint_snapshot_create() to get a consistent snapshot of the internal state. This patch also includes a set of topics and messages associated with endpoints, and implementations of the endpoint-related RESTful API. chan_sip was updated to create endpoints with SIP peers, but the state of the endpoints is not updated with the state of the peer. Along for the ride in this patch is a Stasis test API. This is a stasis_message_sink object, which can be subscribed to a Stasis topic. It has functions for blocking while waiting for conditions in the message sink to be fulfilled. (closes issue ASTERISK-21421) Review: https://reviewboard.asterisk.org/r/2492/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 13:39:08 +00:00
type = stasis_message_type(msg);
ast_test_validate(test, ast_endpoint_snapshot_type() == type);
actual_snapshot = stasis_message_data(msg);
ast_test_validate(test, 0 == actual_snapshot->num_channels);
return AST_TEST_PASS;
}
static int unload_module(void)
{
AST_TEST_UNREGISTER(state_changes);
AST_TEST_UNREGISTER(cache_clear);
AST_TEST_UNREGISTER(channel_messages);
return 0;
}
static int load_module(void)
{
AST_TEST_REGISTER(state_changes);
AST_TEST_REGISTER(cache_clear);
AST_TEST_REGISTER(channel_messages);
return AST_MODULE_LOAD_SUCCESS;
}
AST_MODULE_INFO(ASTERISK_GPL_KEY, AST_MODFLAG_DEFAULT, "Endpoint stasis-related testing",
Initial support for endpoints. An endpoint is an external device/system that may offer/accept channels to/from Asterisk. While this is a very useful concept for end users, it is surprisingly not a core concept within Asterisk itself. This patch defines ast_endpoint as a separate object, which channel drivers may use to expose their concept of an endpoint. As the channel driver creates channels, it can use ast_endpoint_add_channel() to associate channels to the endpoint. This updated the endpoint appropriately, and forwards all of the channel's events to the endpoint's topic. In order to avoid excessive locking on the endpoint object itself, the mutable state is not accessible via getters. Instead, you can create a snapshot using ast_endpoint_snapshot_create() to get a consistent snapshot of the internal state. This patch also includes a set of topics and messages associated with endpoints, and implementations of the endpoint-related RESTful API. chan_sip was updated to create endpoints with SIP peers, but the state of the endpoints is not updated with the state of the peer. Along for the ride in this patch is a Stasis test API. This is a stasis_message_sink object, which can be subscribed to a Stasis topic. It has functions for blocking while waiting for conditions in the message sink to be fulfilled. (closes issue ASTERISK-21421) Review: https://reviewboard.asterisk.org/r/2492/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-05-08 13:39:08 +00:00
.load = load_module,
.unload = unload_module,
.nonoptreq = "res_stasis_test",
);