6 Commits (ca65ddcd199dca4681055b51fc63b906e48f1950)

Author	SHA1	Message	Date
Corey Farrell	0d266cbe02	Stasis: Fix unsafe use of stasis_unsubscribe in modules. ... Many uses of stasis_unsubscribe in modules can be reached through unload. These have been switched to stasis_unsubscribe_and_join. Some subscription callbacks do nothing, for these I've created a noop callback function in stasis.c. This is used by some modules that monitor MWI topics in order to enable cache, since the callback does not become invalid after dlclose it is safe to use stasis_unsubscribe on these, even during module unload. ASTERISK-25121 #close Change-Id: Ifc2549fbd8eef7d703c222978e8f452e2972189c	10 years ago
Matthew Jordan	d79c68d3fb	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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428687 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	dcf1ad14da	Add module support level to ast_module_info structure. Print it in CLI "module show" . ... ASTERISK-23919 #close Reported by Malcolm Davenport Review: https://reviewboard.asterisk.org/r/3802 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419592 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	3eae87fdfe	ARI: Make double subscribe respond with success ... Currently, attempting to subscribe an application to a device state that it has already subscribed to will generate a 500 error response. This will now be treated as a subscription refresh even though ARI subscriptions don't currently support lifetimes and will respond with the normal response for a successful subscription (200 OK). (closes issue ASTERISK-23143) Reported by: Matt Jordan ........ Merged revisions 406775 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@406778 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	7ddfe12aff	res_stasis_device_state: Set resource type for subscriptions to deviceState ... The documentation for ARI already specifies that the device state resource when used for subscribing for events is "deviceState", not "device_state". The code, however, used "device_state"; although this was inconsistent as well in doxygen comments in resource_applications. Because the actual resource being subscribed to is /deviceStates/{device}/, it makes sense for the resource type specifier to be deviceState. Note that the key value in the events is still "device_state". ........ Merged revisions 404437 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404438 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kevin Harwell	ed48377994	ARI: Implement device state API ... Created a data model and implemented functionality for an ARI device state resource. The following operations have been added that allow a user to manipulate an ARI controlled device: Create/Change the state of an ARI controlled device PUT /deviceStates/{deviceName}&{deviceState} Retrieve all ARI controlled devices GET /deviceStates Retrieve the current state of a device GET /deviceStates/{deviceName} Destroy a device-state controlled by ARI DELETE /deviceStates/{deviceName} The ARI controlled device must begin with 'Stasis:'. An example controlled device name would be Stasis:Example. A 'DeviceStateChanged' event has also been added so that an application can subscribe and receive device change events. Any device state, ARI controlled or not, can be subscribed to. While adding the event, the underlying subscription control mechanism was refactored so that all current and future resource subscriptions would be the same. Each event resource must now register itself in order to be able to properly handle [un]subscribes. (issue ASTERISK-22838) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/3025/ ........ Merged revisions 403134 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403135 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago