Summary: | ASTERISK-12728: [patch] Only one custom feature can be executed simultaneously | ||
Reporter: | Emmanuel BUU (neutrino88) | Labels: | |
Date Opened: | 2008-09-13 16:14:30 | Date Closed: | 2008-12-11 10:54:47.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Resources/res_features |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) res_feature.patch | |
Description: | On an asterisk server, there can be only one feature executed simulatenously. Ex: in feature.conf define a feature such as [applicationmap] playmessage => **3,,callee,Macro,play-long-message in extention.conf, define the attached macro [macro-play-long-message] exten => s,1,Playback(longmessage) If you call in an extention with this feature activated (in the variable DYNAMIC_FEATURE), the macro can be triggered by pressing '**3'. If you make a second call to the same extention and try to trigger the SAME macro / feature, the second chan hangs until the first chan has completed the execution of the feature. ****** ADDITIONAL INFORMATION ****** A short code analysis show that when triggering and executing a feature, asterisk locks a global variable containing all the active feature of the system. This lock is remove after feature completion. This is consistent with the behavior described above. A suggested fix would consist in locking this list only during the first DTMF hit then make a copy and work on the copy. I include a small patch that is more a workaround than a proper fix. | ||
Comments: | By: Russell Bryant (russell) 2008-10-06 08:35:13 Thanks for the patch. However, the fix here is going to have to be a bit more complicated. The way that this patch works, a crash could occur, because there is no longer anything ensuring that the feature being accessed doesn't get deleted due to a reload. The fix I would like to see here is to convert the features to astobj2 objects. By: Emmanuel BUU (neutrino88) 2008-10-06 09:10:24 1- What are astobj2 2- how would it fix the fact that a feature would not be deleted in case of module reload ? By: Digium Subversion (svnbot) 2008-12-11 10:54:47.000-0600 Repository: asterisk Revision: 163092 U branches/1.4/res/res_features.c ------------------------------------------------------------------------ r163092 | russell | 2008-12-11 10:54:46 -0600 (Thu, 11 Dec 2008) | 11 lines Fix an issue that made it so you could only have a single caller executing a custom feature at a time. This was especially problematic when custom features ran for any appreciable amount of time. The fix turned out to be quite simple. The dynamic features are now stored in a read/write list instead of a list using a mutex. (closes issue ASTERISK-12728) Reported by: neutrino88 Fix suggested by file ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=163092 |