When I issue a MUTE to a number of channels in my Stasis application, I’m seeing TP queue warnings:
[Jul 28 06:09:09] WARNING[C-00000077] taskprocessor.c: The ‘subm:voice_2-0000005f’ task processor queue reached 500 scheduled tasks again.
Often followed by
[Jul 28 06:22:37] ERROR[C-0000001a] channel.c: FRACK!, Failed assertion bad magic number 0x0 for object 0x7f5e3c198738 (0)
This happens when I’m muting/unmuting just a small number of channels (>15).
The application is driven by an attached .Net app, and makes heavy use of batch conference bridge moves and mute/unmute commands. We’ve had some issues stabilising the interoperation of the two boxes, but these appear to have been ameliorated by increading websocket_write_timeout very significantly. We are left with this residual and nagging issue.
A_procs.txt the taskprocessor list from immediately after the issue (10.7 KB)
A_messages.txt from the messages log(25.2 KB)
A_backtrace.txt a backtrace from the time of the issue(376.0 KB)
The Stasis application (voice_2) is the busiest queue. I’m running the test using SIPP with 120 clients (well above operational levels), but without the RTP traffic we’d normally see in everyday use. I’m running on a fast quad-core system, but as an aside, it would be interesting to know if adding further processing power (cores, memory) would help performance without separating the Stasis app into different instances.