[Freeswitch-users] Playback race condition

Sat Nov 19 12:04:52 MSK 2011

Peter, thanks for pointing me to the right direction. I will try the
execute command, since queueing is exactly what I would need to preserve
consistency across commands (I had an impression that bgapi will give me
this consistency).

Also I like to hear that it is possible to use a single connection since I
have designed the communication with one connection also. May I ask how
many concurrent sessions can your system handle?

Hynek

On Sat, Nov 19, 2011 at 9:35 AM, Peter Olsson <
peter.olsson at visionutveckling.se> wrote:

> If you think about performance I would say it's better to handle this
> without spawning lots of extra threads.
>
> First of all, most common commands can be queued into the the channel
> thread using the execute method (
> http://wiki.freeswitch.org/wiki/Mod_event_socket#execute), this makes it
> possible to queue commands directly to the channel's thread, and the ESL
> session will never wait for the result, it returns immediately.
>
> I've never used uuid_broadcast myself, so I'm not really sure how it's
> handled, but by looking quickly in the code it looks like it shouldn't
> block either, since it's actually just queuing a playback command to the
> channel's thread.
>
> So basically, keep away from uuid_X-commands, and use execute method as
> much as possible, and when using uuid_x-methods, make sure that won't block
> - but if they do, make sure to handle handle the events for the bgapi
> correctly.
>
> I've built a complete IVR system using these methods, with a single ESL
> connection, and I've never had any performace issues.
>
> /Peter
>
> ________________________________________
> Från: freeswitch-users-bounces at lists.freeswitch.org [
> freeswitch-users-bounces at lists.freeswitch.org] f&#246;r Hynek Cihlar [
> hynek.cihlar at gmail.com]
> Skickat: den 19 november 2011 09:12
> Till: FreeSWITCH Users Help
> Ämne: Re: [Freeswitch-users] Playback race condition
>
> Two reasons I am not using api in this case.
>
> 1. Performance
> 2. Doesn't seem to work
>
> 1. Blocking issuing the command will eventually reduce the system
> throughput. Agree this is only a potential theoretical problem and I
> haven't gotten into production where I could get the actual results.
>
> 2. When issuing api uuid_playback and api uuid_break right after, I'm
> always getting an error response from the uuid_break. The ESL message body
> is "-ERR no reply". Nothing in the logs (no idea which log type/level will
> could generate other useful info).
>
> Hynek
>
>
>
> On Sat, Nov 19, 2011 at 8:48 AM, Peter Olsson <
> peter.olsson at visionutveckling.se<mailto:peter.olsson at visionutveckling.se>>
> wrote:
> Since you're using bgapi, it's impossible to guarantee that uuid_broadcast
> has actually executed before you exeute uuid_break (they will be executed
> in two different threads). You will have to do this in a more controlled
> way (wait for events to show up etc.). And also, do you really need to use
> bgapi all the time? I'm not sure how uuid_broadcast is handled, but
> uuid_break is totally safe to use without bgapi, since it will just update
> a flag and then return immediately. I think uuid_broadcast will do the same
> thing - so getting rid of bgapi should be a good ebnough solution.
>
> /Peter
> ________________________________________
> Från: freeswitch-users-bounces at lists.freeswitch.org<mailto:
> freeswitch-users-bounces at lists.freeswitch.org> [
> freeswitch-users-bounces at lists.freeswitch.org<mailto:
> freeswitch-users-bounces at lists.freeswitch.org>] f&#246;r Hynek Cihlar [
> hynek.cihlar at gmail.com<mailto:hynek.cihlar at gmail.com>]
> Skickat: den 19 november 2011 08:31
> Till: FreeSWITCH Users Help
> Ämne: Re: [Freeswitch-users] Playback race condition
>
> As a workaround I put a synthetic a delay between the start and stop of
> the playback. I wouldn't want to keep this solution however since it blocks
> one of the worker threads (decreasing overall system throughput) and
> second, I really don't know what the synthetic delay should be or whether
> it could differ during different conditions like during a high load.
>
> Was anybody facing similar problem? How did you solve it? Am I using the
> API wrong and is there another way to invoke playback/stop?
>
> Thanks!
> Hynek
>
>
>
> On Fri, Nov 18, 2011 at 6:46 PM, Hynek Cihlar <hynek.cihlar at gmail.com
> <mailto:hynek.cihlar at gmail.com><mailto:hynek.cihlar at gmail.com<mailto:
> hynek.cihlar at gmail.com>>> wrote:
> Hello all,
>
> I got on shaky grounds issuing commands to Freeswitch over ESL.
>
> For example, issuing the following commands close enough (on my system at
> around 100 ms and less) causes troubles.
>
> bgapi uuid_broadcast 71f8f250-8ad6-4ab3-855a-3cbc71075fe2
> playback::tone_stream://%(150,4000,425);loops=-1
> <100ms appart
> bgapi uuid_break 71f8f250-8ad6-4ab3-855a-3cbc71075fe2 all
> previous playback is not stopped, the following is queued (not played)
> bgapi uuid_broadcast 71f8f250-8ad6-4ab3-855a-3cbc71075fe2
> playback::tone_stream://%(1000,4000,425);loops=-1
>
> It looks like the first tone playback is not properly initialized when the
> break arrives. Waiting for the start of the first tone playback (waiting
> for the right event) is not a solution, I don't want the tone to be played
> at all if the events come this close.
>
> Any ideas?
>
>
> Hynek
>
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org<mailto:consulting at freeswitch.org>
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org<mailto:
> FreeSWITCH-users at lists.freeswitch.org>
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
> !DSPAM:4ec764af32761901519715!
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20111119/c94472a0/attachment.html 