[Home]

Summary:ASTERISK-00118: [request] Manager: Open Ended Actions Create
Reporter:jayson (jayson)Labels:
Date Opened:2003-08-18 01:04:12Date Closed:2008-01-15 14:42:24.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents: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