[asterisk-bugs] [JIRA] (ASTERISK-24793) Asterisk spirals to high load when audio stream fed to MOH disappears

[Rusty Newton (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-24793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-24793:
------------------------------------

    Assignee: Rusty Newton  (was: univ)
      Status: Reopened  (was: Waiting for Feedback)

> Asterisk spirals to high load when audio stream fed to MOH disappears
> ---------------------------------------------------------------------
>
>                 Key: ASTERISK-24793
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24793
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_musiconhold
>    Affects Versions: 11.4.0, 11.16.0
>         Environment: Linux CentOS 6.6 (latest) 64bit 2.6.32-504.8.1.el6.x86_64 and Linux CentOS 6.4 64bit 2.6.32-358.6.2.el6.x86_64.
>            Reporter: univ
>            Assignee: Rusty Newton
>            Severity: Minor
>         Attachments: issue_24793_log.txt
>
>
> I was unsure whether this should be classified as a bug or improvement. But since, when it happens, it has an impact on the remaining Asterisk functionality, I chose bug.
> I'm feeding several MP3 streams to Asterisk' MusicOnHold like this:
> musiconhold.conf:
> [stream1]
> mode=custom
> application=/var/lib/asterisk/mohstream-stream1.sh
> mohstream-stream1.sh:
> #!/bin/bash
> /usr/bin/mpg123 -q -r 8000 --mono -s http://stream.url
> Everything's fine by default. 250+ MOH streams in parallel on a single Quad Core VM, no problem. Load 0.xx to 1.xx. But as soon as any of the http://stream.url goes down for whatever reason, load will rise to 70, 150 and more. top shows that the asterisk process starts to consume hundreds of % of CPU. Input on the console starts to lag and so does all audio that Asterisk serves to callers. Fix the stream.url and everything's fine again.
> I've checked that the cause is the stream.url that's gone by looking at the mpg123 process with strace, which, by the way, re-spawns constantly and I guess that's part of the problem.



--
This message was sent by Atlassian JIRA
(v6.2#6252)