Paging Server Crash/Music Fade issue #20
Comments
|
Just had it crash again, but this time the service didn't die. The first call after the error was thrown did not audibly play the klaxon, after that it returned to normal. |
|
On further debugging, it appears to be a problem triggered by setting In testing I noticed that 12% of the time there is a 5 second delay before the klaxon is played, and the klaxon gets clipped to its last 0.1 second when this occurs. The polling loop seems to be the root of both the crashes before, and this 5 second delay issue. |
|
Not sure which "crashes before" do you mean there. |
|
Oh, "crashes before" was a reference to these two crashes (#1 & #2). I tried setting loop_wait=1.0 and loop_interval=0.03 which made the same error much more common, and I also tried loop_wait=5.0 and loop_interval=0.03 based on this but the script still threw this error 3 times in 40 runs. |
|
Wrt this issue though:
|
|
As mentioned in an earlier email, I'd suggest that it might be more cost-effective to rewrite this from scratch, maybe using proper python3/asyncio eventloop hooking into libpulse fds in place of this pseudo-synchronous operation. |
|
Yeah, this pseudo-synchronous function seems to be troublesome, planning to refactor this in late June/early July. Would you recommend pulsectl or something else? The error this issue is about seems to happen inconsistently based on my testing, sometimes I can call many times without issue. |
|
Note that when rewriting the script, you'd probably be using different bindings entirely (pjsua2.so swig module, not old python2 pjsua code), which will probably work differently. While it's possible to make pulsectl work with that (see README there), imo copying few ctype defs for only calls you need from there with proper async wrapping would be easier to maintain/understand/debug, given how relatively little this script needs to do. |
Yeah, it's almost certainly some trivial race condition - log all event starting/stopping stuff into single logger (they do locking for proper ordering) and you'd probably see something out of place. EDIT: I hate these mutexes and threads! |
|
Perhaps I could comment out the volume controls/fading entirely and remove this dependency (for now)? I don't mind if the caller can speak while the klaxon is playing, and the music stream feature is currently unused (so adjusting the volume level of the sinks is not needed). |
|
Sorry for the delay. Don't think it'd remove the dependency, as volume-setting is needed all over the place there iirc, and maybe there's some other stuff like moving streams between sinks, which I don't quite remember off the top of my head. Can probably be a workaround, as that part of code switches between loops often to adjust volume in steps, so if race conditions like that pop-up, would be way more likely to happen there. |
|
FYI, pretty sure the cause of this issue is from passwords with special characters (eg: !#!) which are included in passwords generated by FusionPBX. Changing passwords to exclude these characters seems to have resolved this issue. |
Paging server seems to delay inbound calls to let music fade out, not sure if this was what caused the server crash on the 4th call.
The text was updated successfully, but these errors were encountered: