<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).</div>
<div><br></div><div>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?</div>
<div><br></div><div>Hynek</div><br>
<br><br><div class="gmail_quote">On Sat, Nov 19, 2011 at 9:35 AM, Peter Olsson <span dir="ltr"><<a href="mailto:peter.olsson@visionutveckling.se">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;">
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>
<div class="im"><br>
/Peter<br>
<br>
________________________________________<br>
Från: <a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a> [<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a>] f&#246;r Hynek Cihlar [<a href="mailto:hynek.cihlar@gmail.com">hynek.cihlar@gmail.com</a>]<br>
Skickat: den 19 november 2011 09:12<br>
Till: FreeSWITCH Users Help<br>
Ämne: Re: [Freeswitch-users] Playback race condition<br>
<br>
</div><div class="im">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 class="im">On Sat, Nov 19, 2011 at 8:48 AM, Peter Olsson <<a href="mailto:peter.olsson@visionutveckling.se">peter.olsson@visionutveckling.se</a><mailto:<a href="mailto:peter.olsson@visionutveckling.se">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">freeswitch-users-bounces@lists.freeswitch.org</a><mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a>> [<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a><mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org">freeswitch-users-bounces@lists.freeswitch.org</a>>] f&#246;r Hynek Cihlar [<a href="mailto:hynek.cihlar@gmail.com">hynek.cihlar@gmail.com</a><mailto:<a href="mailto:hynek.cihlar@gmail.com">hynek.cihlar@gmail.com</a>>]<br>
<div class="im">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 class="im">On Fri, Nov 18, 2011 at 6:46 PM, Hynek Cihlar <<a href="mailto:hynek.cihlar@gmail.com">hynek.cihlar@gmail.com</a><mailto:<a href="mailto:hynek.cihlar@gmail.com">hynek.cihlar@gmail.com</a>><mailto:<a href="mailto:hynek.cihlar@gmail.com">hynek.cihlar@gmail.com</a><mailto:<a href="mailto:hynek.cihlar@gmail.com">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>
</div><div class="im">_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
</div><a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><mailto:<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a>><br>
<div class="im"><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">FreeSWITCH-users@lists.freeswitch.org</a><mailto:<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a>><br>
<div class="im"><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:4ec764af32761901519715!<br>
<div><div></div><div class="h5"><br>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">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">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>