Summary: | ASTERISK-00118: [request] Manager: Open Ended Actions Create | ||
Reporter: | jayson (jayson) | Labels: | |
Date Opened: | 2003-08-18 01:04:12 | Date Closed: | 2008-01-15 14:42:24.000-0600 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) mgr.patch | |
Description: | Certain types of requests (Status) don't have a good way to indicate when they are finished. Right now we either rely on their results being "uninterrupted" (when the Status events stop coming, the Status is done) or they require us to implement our manager applications in such a way as to ignore whether the command is finished. This is obviously a recipe to create weird behavior when there are slight changes in the way the manager responds. As such, I'd request that such Action completion be explicit. The easiest way is for actions to emit their Response after their data events (in the case of Status-like Actions). This also would make it much more possible to extend Asterisk so that long-running Actions could interleave their responses (trivially, if we implement ActionIDs, see bug ASTERISK-117). ****** ADDITIONAL INFORMATION ****** This has become a real issue for me. I had a buggy script create a massive number of local channels. My manager then further compounded the problem by shoving Status requests down the manager socket faster than they were fulfilled (once per second). Load reached 0.8 on a fairly beefy machine. Since both ends of the manager appeared to block when their buffers got filled, the problem was minor. This would have killed a machine if * (and my manager) were extended to handle the management protocol in a truly asynchronous, buffered manner. I believe this should eventually be a goal anyways--especially if were intend to scale to managing many thousands of active channels. Coupling this with my other request for action IDs (bug ASTERISK-117) also allows for putting a Start->In Progress->Finished state machine to Actions (like is already available with Channel Events via Newchannel->Newstate/Link/Up/Unlink/Newexten->Hangup). It also helps solve issues that we may eventally encounter involving interleaved responses to actions (or events interleaved into action responses). | ||
Comments: | By: Mark Spencer (markster) 2003-08-18 16:21:43 I could see adding a "StatusComplete" event at the end of the status executing if you want. Similar for queue status. Add a patch. I assume you've already done a disclaimer? By: jayson (jayson) 2003-08-19 17:15:44 Already done a disclaimer. I'll implement it. I very much appreciate this specific type of enhancement. By: John Todd (jtodd) 2003-10-16 03:10:34 jayson - any progress here? By: jerjer (jerjer) 2003-11-05 00:49:54.000-0600 What is the status of this? By: jerjer (jerjer) 2003-11-13 02:36:10.000-0600 Bug 122 is resolved. If i don't hear anything in a week i'll resolve this bug also By: jerjer (jerjer) 2003-11-13 02:40:21.000-0600 er Bug 121 By: Anthony Minessale (anthm) 2003-11-13 10:08:18.000-0600 the manager interface would work better if it has a cut and dry protocol to follow with http-type headers and other mechanisms to help remote applications communicate properly. By: jayson (jayson) 2004-01-28 09:35:00.000-0600 Try this patch. (will attach to ticket) By: Mark Spencer (markster) 2004-01-28 20:29:50.000-0600 Fixed in CVS By: Digium Subversion (svnbot) 2008-01-15 14:42:24.000-0600 Repository: asterisk Revision: 2088 U trunk/manager.c ------------------------------------------------------------------------ r2088 | markster | 2008-01-15 14:42:23 -0600 (Tue, 15 Jan 2008) | 2 lines Emit status complete message when status is finished (bug ASTERISK-118) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=2088 |