summaryrefslogtreecommitdiff
path: root/CHANGES
diff options
context:
space:
mode:
authorMatthew Jordan <mjordan@digium.com>2014-12-01 17:59:21 +0000
committerMatthew Jordan <mjordan@digium.com>2014-12-01 17:59:21 +0000
commit1106e8fd0f831c79eb2a7cf079739561da11d6ef (patch)
tree3e841771528c621760a6b0471935bc432e704054 /CHANGES
parentef9ca8bc32c7cce781c35bca81d9ae544fd22dae (diff)
main/stasis: Allow subscriptions to use a threadpool for message delivery
Prior to this patch, all Stasis subscriptions would receive a dedicated thread for servicing published messages. In contrast, prior to r400178 (see review https://reviewboard.asterisk.org/r/2881/), the subscriptions shared a thread pool. It was discovered during some initial work on Stasis that, for a low subscription count with high message throughput, the threadpool was not as performant as simply having a dedicated thread per subscriber. For situations where a subscriber receives a substantial number of messages and is always present, the model of having a dedicated thread per subscriber makes sense. While we still have plenty of subscriptions that would follow this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into the following two categories: * Large number of subscriptions, specifically those tied to endpoints/peers. * Low number of messages. Some subscriptions exist specifically to coordinate a single message - the subscription is created, a message is published, the delivery is synchronized, and the subscription is destroyed. In both of the latter two cases, creating a dedicated thread is wasteful (and in the case of a large number of peers/endpoints, harmful). In those cases, having shared delivery threads is far more performant. This patch adds the ability of a subscriber to Stasis to choose whether or not their messages are dispatched on a dedicated thread or on a threadpool. The threadpool is configurable through stasis.conf. Review: https://reviewboard.asterisk.org/r/4193 ASTERISK-24533 #close Reported by: xrobau Tested by: xrobau ........ Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428687 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Diffstat (limited to 'CHANGES')
-rw-r--r--CHANGES12
1 files changed, 11 insertions, 1 deletions
diff --git a/CHANGES b/CHANGES
index 0c46e0d6d..f2c1314dd 100644
--- a/CHANGES
+++ b/CHANGES
@@ -39,6 +39,16 @@ chan_pjsip
the message will automatically be associated with the configured endpoint on the
outbound registration.
+
+Core
+------------------
+ * The core of Asterisk uses a message bus called "Stasis" to distribute
+ information to internal components. For performance reasons, the message
+ distribution was modified to make use of a thread pool instead of a
+ dedicated thread per consumer in certain cases. The initial settings for
+ the thread pool can now be configured in 'stasis.conf'.
+
+
Functions
------------------
@@ -355,7 +365,7 @@ AMI
* AMI action PJSIPNotify may now send to a URI instead of only to a PJSIP
endpoint as long as a default outbound endpoint is set. This also applies
to the equivalent CLI command (pjsip send notify)
-
+
* The AMI action PJSIPShowEndpoint now includes ContactStatusDetail sections
that give information on Asterisk's attempts to qualify the endpoint.