[Freeswitch-users] Playback race condition

Anthony Minessale anthony.minessale at gmail.com
Sun Nov 20 06:28:10 MSK 2011 

s/had/hand/

On Sat, Nov 19, 2011 at 9:27 PM, Anthony Minessale <
anthony.minessale at gmail.com> wrote:

> Every way you are discussing does it the same way, doing it over bgapi
> just wastes an extra thread for no reason.
>
> All of the above queue the command to the session and it will not execute
> it until the next time its convenient for the session to execute
> queued instructions.
>
> So any way you slice it, unless you wait for the execute event telling you
> that the playback you tried to start, has actually started then its not
> going to help.
>
> You are most likely trying to had implement some convention that is dumbed
> down to one command already in FS so I suggest you re-evaluate what you are
> even trying to do.
>
>
>
> On Sat, Nov 19, 2011 at 3:37 AM, Hynek Cihlar <hynek.cihlar at gmail.com>wrote:
>
>> So I changed the uuid_X-commands to execute and the use case with
>> stopping tone playback works like a charm now!
>>
>> Regarding the blocking, you are right. I'm limiting blocking (and context
>> switching) by handling all events and issuing commands always on one (and
>> the same) thread per session. This design also allows me to simplify the
>> programming model, decrease concurrency bugs, simplify debugging, etc.
>> That's why the synthetic delay was giving me troubles since the events and
>> commands must fly through as fast as possible.
>>
>> Thanks again!
>>
>> Hynek
>>
>>
>>
>>
>> On Sat, Nov 19, 2011 at 10:28 AM, Peter Olsson <
>> peter.olsson at visionutveckling.se> wrote:
>>
>>> bgapi can of course be used also, and in some cases you might still need
>>> it. But the important thing to keep in mind when doing bgapi is to handle
>>> the events correctly. When executing bgapi you will get a job-id back, this
>>> job id must then be stored internally, so you can link this to the
>>> background job event.
>>>
>>> I try to use the sendMsg/execute as much as possible, you will get
>>> CHANNEL_EXECUTE/CHANNEL_EXECUTE_COMPLETE events, so you will always know
>>> what's going on.
>>>
>>> I've only tested my system for about 100 concurrent calls, but that was
>>> handled without any problems at all. What's really important is to make
>>> really sure you never execute something that will block - since that will
>>> cause everything to "hang".
>>>
>>> /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 10:04
>>> Till: FreeSWITCH Users Help
>>> Ämne: Re: [Freeswitch-users] Playback race condition
>>>
>>> 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<mailto: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<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 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
>>> ><mailto: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><mailto:
>>> 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><mailto:
>>> 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><mailto:
>>> 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>><mailto: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><mailto:
>>> 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><mailto:
>>> 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
>>>
>>>
>>>
>>> _________________________________________________________________________
>>> 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:4ec770ca32761488716642!
>>>
>>> _________________________________________________________________________
>>> 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
>>>
>>
>>
>> _________________________________________________________________________
>> 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
>>
>>
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
> Twitter: http://twitter.com/FreeSWITCH_wire
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org
> googletalk:conf+888 at conference.freeswitch.org
> pstn:+19193869900
>



-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20111119/2749bc9a/attachment-0001.html

Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users mailing list