<div>So I changed the uuid_X-commands to execute and the use case with stopping tone playback works like a charm now!</div><div><br></div><div>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.</div>
<div><br></div><div>Thanks again!</div>
<br clear="all">Hynek<br><br>
<br><br><div class="gmail_quote">On Sat, Nov 19, 2011 at 10:28 AM, Peter Olsson <span dir="ltr"><<a href="mailto:peter.olsson@visionutveckling.se" target="_blank">peter.olsson@visionutveckling.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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.<br>
<br>
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".<br>
<div><br>
/Peter<br>
________________________________________<br>
Från: <a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a> [<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a>] f&#246;r Hynek Cihlar [<a href="mailto:hynek.cihlar@gmail.com" target="_blank">hynek.cihlar@gmail.com</a>]<br>
</div>Skickat: den 19 november 2011 10:04<br>
<div>Till: FreeSWITCH Users Help<br>
Ämne: Re: [Freeswitch-users] Playback race condition<br>
<br>
</div><div>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).<br>
<br>
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?<br>
<br>
Hynek<br>
<br>
<br>
<br>
</div><div>On Sat, Nov 19, 2011 at 9:35 AM, Peter Olsson <<a href="mailto:peter.olsson@visionutveckling.se" target="_blank">peter.olsson@visionutveckling.se</a><mailto:<a href="mailto:peter.olsson@visionutveckling.se" target="_blank">peter.olsson@visionutveckling.se</a>>> wrote:<br>
If you think about performance I would say it's better to handle this without spawning lots of extra threads.<br>
<br>
First of all, most common commands can be queued into the the channel thread using the execute method (<a href="http://wiki.freeswitch.org/wiki/Mod_event_socket#execute" target="_blank">http://wiki.freeswitch.org/wiki/Mod_event_socket#execute</a>), 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I've built a complete IVR system using these methods, with a single ESL connection, and I've never had any performace issues.<br>
<br>
/Peter<br>
<br>
________________________________________<br>
</div><div>Från: <a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a><mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a>> [<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a><mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a>>] f&#246;r Hynek Cihlar [<a href="mailto:hynek.cihlar@gmail.com" target="_blank">hynek.cihlar@gmail.com</a><mailto:<a href="mailto:hynek.cihlar@gmail.com" target="_blank">hynek.cihlar@gmail.com</a>>]<br>
</div><div>Skickat: den 19 november 2011 09:12<br>
Till: FreeSWITCH Users Help<br>
Ämne: Re: [Freeswitch-users] Playback race condition<br>
<br>
Two reasons I am not using api in this case.<br>
<br>
1. Performance<br>
2. Doesn't seem to work<br>
<br>
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.<br>
<br>
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).<br>
<br>
Hynek<br>
<br>
<br>
<br>
</div><div>On Sat, Nov 19, 2011 at 8:48 AM, Peter Olsson <<a href="mailto:peter.olsson@visionutveckling.se" target="_blank">peter.olsson@visionutveckling.se</a><mailto:<a href="mailto:peter.olsson@visionutveckling.se" target="_blank">peter.olsson@visionutveckling.se</a>><mailto:<a href="mailto:peter.olsson@visionutveckling.se" target="_blank">peter.olsson@visionutveckling.se</a><mailto:<a href="mailto:peter.olsson@visionutveckling.se" target="_blank">peter.olsson@visionutveckling.se</a>>>> wrote:<br>
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.<br>
<br>
/Peter<br>
________________________________________<br>
</div>Från: <a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a><mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a>><mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a><mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a>>> [<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a><mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a>><mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a><mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a>>>] f&#246;r Hynek Cihlar [<a href="mailto:hynek.cihlar@gmail.com" target="_blank">hynek.cihlar@gmail.com</a><mailto:<a href="mailto:hynek.cihlar@gmail.com" target="_blank">hynek.cihlar@gmail.com</a>><mailto:<a href="mailto:hynek.cihlar@gmail.com" target="_blank">hynek.cihlar@gmail.com</a><mailto:<a href="mailto:hynek.cihlar@gmail.com" target="_blank">hynek.cihlar@gmail.com</a>>>]<br>
<div>Skickat: den 19 november 2011 08:31<br>
Till: FreeSWITCH Users Help<br>
Ämne: Re: [Freeswitch-users] Playback race condition<br>
<br>
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.<br>
<br>
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?<br>
<br>
Thanks!<br>
Hynek<br>
<br>
<br>
<br>
</div><div>On Fri, Nov 18, 2011 at 6:46 PM, Hynek Cihlar <<a href="mailto:hynek.cihlar@gmail.com" target="_blank">hynek.cihlar@gmail.com</a><mailto:<a href="mailto:hynek.cihlar@gmail.com" target="_blank">hynek.cihlar@gmail.com</a>><mailto:<a href="mailto:hynek.cihlar@gmail.com" target="_blank">hynek.cihlar@gmail.com</a><mailto:<a href="mailto:hynek.cihlar@gmail.com" target="_blank">hynek.cihlar@gmail.com</a>>><mailto:<a href="mailto:hynek.cihlar@gmail.com" target="_blank">hynek.cihlar@gmail.com</a><mailto:<a href="mailto:hynek.cihlar@gmail.com" target="_blank">hynek.cihlar@gmail.com</a>><mailto:<a href="mailto:hynek.cihlar@gmail.com" target="_blank">hynek.cihlar@gmail.com</a><mailto:<a href="mailto:hynek.cihlar@gmail.com" target="_blank">hynek.cihlar@gmail.com</a>>>>> wrote:<br>
Hello all,<br>
<br>
I got on shaky grounds issuing commands to Freeswitch over ESL.<br>
<br>
For example, issuing the following commands close enough (on my system at around 100 ms and less) causes troubles.<br>
<br>
bgapi uuid_broadcast 71f8f250-8ad6-4ab3-855a-3cbc71075fe2 playback::tone_stream://%(150,4000,425);loops=-1<br>
<100ms appart<br>
bgapi uuid_break 71f8f250-8ad6-4ab3-855a-3cbc71075fe2 all<br>
previous playback is not stopped, the following is queued (not played)<br>
bgapi uuid_broadcast 71f8f250-8ad6-4ab3-855a-3cbc71075fe2 playback::tone_stream://%(1000,4000,425);loops=-1<br>
<br>
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.<br>
<br>
Any ideas?<br>
<br>
<br>
Hynek<br>
<br>
<br>
<br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
</div><a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><mailto:<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a>><mailto:<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><mailto:<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a>>><br>
<div><a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
</div><a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><mailto:<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a>><mailto:<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><mailto:<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a>>><br>
<div><a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
<br>
<br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><mailto:<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a>><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><mailto:<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a>><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
</div>!DSPAM:4ec770ca32761488716642!<br>
<div><div></div><div><br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br>