Warning Exceptionally long voice queue length


I recently upgraded from 17.x to 18.3. Since the upgrade I’ve been observing occasional

“Exceptionally long voice queue length queuing to Local/number-id…”

It doesn’t happen all the time and as far as I can tell it doesn’t break anything either. I originate calls from node js , using one of the npm packages over AMI Manager and after successful result it gets sent to designated queue. When I receive this error, I check the queue “Show Queue QueueName” and the call is present awaiting to be answered. The ful line is

WARNING[578963][C-0001aed9]: channel.c:1086 __ast_queue_frame: Exceptionally long voice queue length queuing to Local/numberDialed@queueName-00005288;1

I saw some similar issues reported and the most recent incident reported seems to have been fixed in v17x.

Any ideas?

Thanks in advance, Ucin

The message means that audio frames are queued up but the thread that should be reading them isn’t doing so, or isn’t doing so fast enough. A backtrace[1] would be needed.

[1] Getting a Backtrace - Asterisk Project - Asterisk Project Wiki.

1 Like

Hi Jcolp,

Thanks for your reply. I’ve checked the link you’ve provided, which option would be the appropriate one to follow? It’s not a crashing issue , but also there is one thing. This is a high production live system. I would regret it if I broke something in the process.


The link I gave was for a deadlock which would be the one. Executing it will freeze Asterisk for a few seconds, it depends on usage and how much memory is in use. Otherwise without such a thing one can only guess vaguely. If it’s a highly used system, then a backtrace may not even be enough and it may be the result of that in some way and not a deadlock.

1 Like

I get your point, but 3 days ago before performing the upgrade I had other issue but not this one. Those are gone now this one started. System is running on an 8 core 32gb ram dedicated server.

does this give any useful information ?

root        9349 99.7  0.0  65644  7224 ?        R    Apr23 3842:20 rasterisk r
root        9527 18.6  1.3 5460096 452300 ?      Sl   Apr23 719:26 /usr/sbin/asterisk -f -vvvg -c

cpu is not actually 100% centos8 reports per core so real 100% usage is actually 800% when yo urun the top command

The asterisk console shouldn’t be consuming more CPU than the main asterisk process. Have you got an extreme level of logging to the console?

Hi David, I coudnt understand your question. Could you give me an example? or anything I can do to provide more info. However, is this normal? it’s the first time I’m seeing two asterisk processes.

 9349 root      20   0   65644   7224   6260 R 100.0   0.0   3902:11 asterisk
 9527 root      20   0 5456596 451332  33608 S   0.3   1.4 723:04.80 asterisk


An example would be any setting of logging that caused the console output to scroll past a great deal faster than you could read it.

rasterisk is asterisk running as the console and it should only be consuming CPU when you are entering a command or it is displaying output. If you did have an excess amount of logging, it might well result in production threads being delayed.

currently the load is low , and I’m not actively using astersik CLI console. Is this normal ?

Maybe I did something worng during upgrade or did not perform a step I should have. Just followed normal instructions I could find. Except I just realized that I did not perform any of the clean / dist-clean options.

restarted asterisk.service, seems better
but do you see anything wrong with below SS

Maybe I should re-run

  • make dist-clean

  • ./configure --with-jansson-bundled

  • make menuselect

  • make && make install

  • make config

in this order. Unless any additional steps necessary. This should keep old settings as well as spool(how about modules?) directory and other directories untouched . As the make dist-clean only removes “all files generated by make and configure” am I right?

I wouldn’t run make install or make config without first stopping the daemon. The best that can happen if you don’t do that, is that the old versions continue to run until a new shared library has to be loaded. The worst is that things start breaking immediately.

Did you by any chance install codecs for v17 ? They might be not comptabile with v18. Same goes for any external tools.

hi, yes I did . Opus and g729 .

But after the upgrade it did flash a warning that those might not be compatible with the new version. So I went and replaced those with the v18 versions. I still suspec that since I did not perform the preliminary make clean / distclean , it probably re-written the whole configuration(while some old config may still be present) and this may be the source of the problem.

I will be testing this again tomorrow. However, as for the CPU usage of the processes rasterisk and asterisk , after service stop / start that seems to be OK now. I may need to re-do the whole(upgrading process) thing again

Only make samples writes the configuration proper.

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