Manager is a critical API of Asterisk used by many pieces of software to know what is going on in Asterisk and to also control certain aspects of it. Over the lifetime of manager, though, it has seen relatively few core changes. There have been some ancillary changes such as improving filtering but from an event perspective it hasn’t changed that much. The most recent change was really when Asterisk moved to an internal message bus and manager was changed to use it, for both queueing manager events from parts of Asterisk and also for handling the queued events.
This has now changed (or else I wouldn’t be writing about it).
For the longest time manager used a single event queue for ALL sessions. This queue was a linked list of events. A consequence of this was that each session HAD to wake up and go through the events, even if they weren’t interested or were never going to send the event. Without waking up they would never get to the events they were actually interested in. Periodically an additional thread would wake up and remove any events that were no longer needed, instead of having them be removed immediately when they were no longer used. Put this all together and you had multiple threads hammering that linked list in different ways slowing each other down.
This queueing has now been changed to be more simple and optimized. Each event is now an ao2 reference counted object with the event contents built directly on the event (instead of copying finished event text). Once an event is no longer needed it is immediately freed instead of waiting for a cleanup thread. Each session now has its own queue using a vector of pointers. Contention between queueing and queue handling on a session is minimized by having queue handling “steal” the queue of events for a session and immediately release the lock, reducing how long the queueing of new events is blocked. Since each session has its own queue some quick filtering can now also be done (category checking) before queueing to a session so that a session only receives applicable events and thus only wakes up when events it is interested in are actually available. The method we use to wake up sessions has also changed to an alert pipe which better aligns with how sessions normally wait for data from connections.
Put this all together and it takes less time to handle queued events in Asterisk, which raises the ceiling on the manager taskprocessor that people have seen come up in logs. Does this eliminate the possibility of the taskprocessor message though? No. It’s always possible to queue events faster than they can be given to sessions. The only way to completely solve the manager taskprocessor is to not use a taskprocessor. This may come in the future, but it has a consequence of blocking anything that queues a manager event on the process of queueing to the sessions and so I would like to see how these changes do first.
These improvements are available as of Asterisk 20.21.0, 22.11.0, and 23.5.0.
