Asterisk stasis pool control

Recently I registered new 100 sips ( total 300 ) and some agents and I start to receive this message from asterisk:

WARNING[103660][C-000008d4]: taskprocessor.c:1110 taskprocessor_push: The ‘stasis/pool-control’ task processor queue reached 500 scheduled tasks again.

What is this? I did a search but dont found some answer, theres a way to disable this? (asterisk 13.26.0)

Asterisk 13 is two months short of end of life and is currently only receiving security fixes.

It means an internal queue got rather large, but nothing has yet broken. You can stop the message by removing the WARNING category from relevant sections in logger.conf, or you could edit out the specific warning from the source code, or change the warning limit in the source code.

I haven’t looked at the detailed internal structure of Asterisk since before stasis was introduced, but my understanding is that it moved from a structure in which individual threads acquired lots of locks, and were prone to deadlocks, to one in which parallelism was achieved more by the use of message passing, and stasis is the message passing infrastructure.

1 Like

How I change this limit in source code? I never get it just edit the .conf files in /etc/asterisk
I thought this was affecting the asterisk because I wasn’t able to pause or login agents and the machine resources is ok ( cpu, memory, etc ), you think some queue is possible the problem?

This is not a telephony queue; it is a queue of internal processing work.

There is no point in trying to do anything with an end of life version. You should upgrade. Asterisk 13.26.0 is a long way behind the leading edge, even for Asterisk 13. There will be lots of known but unfixed bugs in it.

Changing the source code was included for completeness. Changing the limit only changes when the message is produced, it does nothing about the underlying problem and its effects. The queue overflowing suggests that Asterisk is unable to keep up with the amount of work needed, or there is a deadlock. The message represents a symptom of an overload and the login failures would seem to be a more direct indication of an underlying problem.

Are you doing anything that could delay processing, like accessing a database on a remote machine?

1 Like

externally I just use the ami api’s, I’m using nodejs with the lib asterisk-ami-client to make actions/commands and I use this with frequency for the call center get the info of agents loggeds, queues, add agents, sips, etc, dont know if this can delay the processing but is the only thing I use more

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.