Playback race condition
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
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@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
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@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Hynek Cihlar [hynek.cihlar@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@gmail.com<mailto:hynek.cihlar@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 !DSPAM:4ec75b5732763454765634!
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@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@lists.freeswitch.org [ freeswitch-users-bounces@lists.freeswitch.org] för Hynek Cihlar [ hynek.cihlar@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@gmail.com <mailto:hynek.cihlar@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
!DSPAM:4ec75b5732763454765634!
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Hynek Cihlar [hynek.cihlar@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@visionutveckling.se<mailto:peter.olsson@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@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] för Hynek Cihlar [hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@gmail.com<mailto:hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@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!
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@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@lists.freeswitch.org [ freeswitch-users-bounces@lists.freeswitch.org] för Hynek Cihlar [ hynek.cihlar@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@visionutveckling.se<mailto:peter.olsson@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@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org> [ freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>] för Hynek Cihlar [ hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@gmail.com <mailto:hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@lists.freeswitch.org [freeswitch-users-bounces@lists.freeswitch.org] för Hynek Cihlar [hynek.cihlar@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@visionutveckling.se<mailto:peter.olsson@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@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org> [freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>] för Hynek Cihlar [hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@visionutveckling.se<mailto:peter.olsson@visionutveckling.se><mailto:peter.olsson@visionutveckling.se<mailto:peter.olsson@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@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org><mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>> [freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org><mailto:freeswitch-users-bounces@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>>] för Hynek Cihlar [hynek.cihlar@gmail.com<mailto:hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@gmail.com<mailto:hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto:hynek.cihlar@gmail.com>><mailto:hynek.cihlar@gmail.com<mailto:hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@freeswitch.org<mailto:consulting@freeswitch.org><mailto:consulting@freeswitch.org<mailto:consulting@freeswitch.org>> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org><mailto:FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@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!
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@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@lists.freeswitch.org [ freeswitch-users-bounces@lists.freeswitch.org] för Hynek Cihlar [ hynek.cihlar@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@visionutveckling.se<mailto:peter.olsson@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@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org> [ freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>] för Hynek Cihlar [ hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@visionutveckling.se<mailto:peter.olsson@visionutveckling.se
<mailto:peter.olsson@visionutveckling.se<mailto: peter.olsson@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@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org><mailto: freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>> [ freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org><mailto: freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>>] för Hynek Cihlar [ hynek.cihlar@gmail.com<mailto:hynek.cihlar@gmail.com><mailto: hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@gmail.com <mailto:hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@gmail.com>><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@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@freeswitch.org<mailto:consulting@freeswitch.org><mailto: consulting@freeswitch.org<mailto:consulting@freeswitch.org>> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@lists.freeswitch.org><mailto: FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@lists.freeswitch.org [ freeswitch-users-bounces@lists.freeswitch.org] för Hynek Cihlar [ hynek.cihlar@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@visionutveckling.se<mailto:peter.olsson@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@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org> [ freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>] för Hynek Cihlar [ hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@visionutveckling.se<mailto:peter.olsson@visionutveckling.se
<mailto:peter.olsson@visionutveckling.se<mailto: peter.olsson@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@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org><mailto: freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>> [ freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org><mailto: freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>>] för Hynek Cihlar [ hynek.cihlar@gmail.com<mailto:hynek.cihlar@gmail.com><mailto: hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@gmail.com <mailto:hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@gmail.com>><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@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@freeswitch.org<mailto:consulting@freeswitch.org><mailto: consulting@freeswitch.org<mailto:consulting@freeswitch.org>> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@lists.freeswitch.org><mailto: FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
s/had/hand/ On Sat, Nov 19, 2011 at 9:27 PM, Anthony Minessale < anthony.minessale@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@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@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@lists.freeswitch.org [ freeswitch-users-bounces@lists.freeswitch.org] för Hynek Cihlar [ hynek.cihlar@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@visionutveckling.se<mailto:peter.olsson@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@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org> [ freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>] för Hynek Cihlar [ hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@visionutveckling.se<mailto:peter.olsson@visionutveckling.se
<mailto:peter.olsson@visionutveckling.se<mailto: peter.olsson@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@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org><mailto: freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>> [ freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org><mailto: freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>>] för Hynek Cihlar [ hynek.cihlar@gmail.com<mailto:hynek.cihlar@gmail.com><mailto: hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@gmail.com <mailto:hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@gmail.com>><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@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@freeswitch.org<mailto:consulting@freeswitch.org><mailto: consulting@freeswitch.org<mailto:consulting@freeswitch.org>> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@lists.freeswitch.org><mailto: FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
So why would the bgapi uuid_break all fail if it queues the same way as execute does? Hynek On Sun, Nov 20, 2011 at 4:27 AM, Anthony Minessale < anthony.minessale@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@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@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@lists.freeswitch.org [ freeswitch-users-bounces@lists.freeswitch.org] för Hynek Cihlar [ hynek.cihlar@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@visionutveckling.se<mailto:peter.olsson@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@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org> [ freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>] för Hynek Cihlar [ hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@visionutveckling.se<mailto:peter.olsson@visionutveckling.se
<mailto:peter.olsson@visionutveckling.se<mailto: peter.olsson@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@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org><mailto: freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>> [ freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org><mailto: freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>>] för Hynek Cihlar [ hynek.cihlar@gmail.com<mailto:hynek.cihlar@gmail.com><mailto: hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@gmail.com <mailto:hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@gmail.com>><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@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@freeswitch.org<mailto:consulting@freeswitch.org><mailto: consulting@freeswitch.org<mailto:consulting@freeswitch.org>> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@lists.freeswitch.org><mailto: FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
execute over event socket does the same thing as broadcast: The channel is very busy, its doing I/O in a very critical loop in its own thread. You cannot simply gain access to it and make it start executing your application because then it would be doing it inside that other thread and possibly stopping it when it's supposed to be doing something else. Instead the instruction is queued to the channel and the channel does periodic calls to see if it has any tasks to execute when its tolerable to perform such a task and also ensuring its carried out in it's own dedicated session thread.
From the time you send the command there is an expected latency until the command is actually executed. From your application you should send the command then wait until you receive the channel_execute corresponding to the desired command before continuing and having clearance to send the uuid_break.
On Sun, Nov 20, 2011 at 2:07 AM, Hynek Cihlar <hynek.cihlar@gmail.com>wrote:
So why would the bgapi uuid_break all fail if it queues the same way as execute does?
Hynek
On Sun, Nov 20, 2011 at 4:27 AM, Anthony Minessale < anthony.minessale@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@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@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@lists.freeswitch.org [ freeswitch-users-bounces@lists.freeswitch.org] för Hynek Cihlar [ hynek.cihlar@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@visionutveckling.se<mailto: peter.olsson@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@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org> [ freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>] för Hynek Cihlar [ hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@visionutveckling.se<mailto: peter.olsson@visionutveckling.se><mailto: peter.olsson@visionutveckling.se<mailto: peter.olsson@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@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org><mailto: freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>> [ freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org><mailto: freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>>] för Hynek Cihlar [hynek.cihlar@gmail.com<mailto:hynek.cihlar@gmail.com><mailto: hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@gmail.com <mailto:hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@gmail.com>><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@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@freeswitch.org<mailto:consulting@freeswitch.org><mailto: consulting@freeswitch.org<mailto:consulting@freeswitch.org>> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@lists.freeswitch.org><mailto: FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
I send execute playback at time t0. I send execute break all also at time t0. Execute playback is queued in the channel queue. Execute break all is also queued in the channel queue. Channel thread picks up the execute playback, posts the execute notification, playback is queued for playback. Channel thread picks up the execute break all command... Now, what is the particular reason that channel thread cannot stop the initiated playback? Having to wait for the execute notification to be able to stop the playback makes the esl protocol unnecessary complicated. It's like having to wait for a TV to come up to be able to turn it off. Sent from my mobile device On Nov 21, 2011, at 18:01, Anthony Minessale <anthony.minessale@gmail.com> wrote: execute over event socket does the same thing as broadcast: The channel is very busy, its doing I/O in a very critical loop in its own thread. You cannot simply gain access to it and make it start executing your application because then it would be doing it inside that other thread and possibly stopping it when it's supposed to be doing something else. Instead the instruction is queued to the channel and the channel does periodic calls to see if it has any tasks to execute when its tolerable to perform such a task and also ensuring its carried out in it's own dedicated session thread.
From the time you send the command there is an expected latency until the command is actually executed. From your application you should send the command then wait until you receive the channel_execute corresponding to the desired command before continuing and having clearance to send the uuid_break.
On Sun, Nov 20, 2011 at 2:07 AM, Hynek Cihlar <hynek.cihlar@gmail.com>wrote:
So why would the bgapi uuid_break all fail if it queues the same way as execute does?
Hynek
On Sun, Nov 20, 2011 at 4:27 AM, Anthony Minessale < anthony.minessale@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@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@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@lists.freeswitch.org [ freeswitch-users-bounces@lists.freeswitch.org] för Hynek Cihlar [ hynek.cihlar@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@visionutveckling.se<mailto: peter.olsson@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@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org> [ freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>] för Hynek Cihlar [ hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@visionutveckling.se<mailto: peter.olsson@visionutveckling.se><mailto: peter.olsson@visionutveckling.se<mailto: peter.olsson@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@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org><mailto: freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>> [ freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org><mailto: freeswitch-users-bounces@lists.freeswitch.org<mailto: freeswitch-users-bounces@lists.freeswitch.org>>] för Hynek Cihlar [hynek.cihlar@gmail.com<mailto:hynek.cihlar@gmail.com><mailto: hynek.cihlar@gmail.com<mailto:hynek.cihlar@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@gmail.com <mailto:hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@gmail.com>><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@gmail.com><mailto:hynek.cihlar@gmail.com<mailto: hynek.cihlar@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@freeswitch.org<mailto:consulting@freeswitch.org><mailto: consulting@freeswitch.org<mailto:consulting@freeswitch.org>> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@lists.freeswitch.org><mailto: FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@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@freeswitch.org<mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto: FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org pstn:+19193869900 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Your tone has changed to be unsatisfactorily arrogant to warrant my attention. Please refrain from any more disrespectful analogies. It would be like you came to a free forum to get help on a free software then questioned the response from the guy who designed it..... oh wait that's not an analogy that's what you are doing! If you sent sendevent with execute to send the playback then sent another one to execute break all (Assuming you did not have event_lock header which will force it to execute each instruction one at a time) it would indeed execute in order. You asked about using broadcast and uuid_break (broadcast is the same as sendmsg + execute) uuid_break is instant real time call so if you broadcast then uuid_break the break will easily beat the queuing. BTW I have 3 TV in my house all of which require you to wait for them to come all the way up to shut them back down. On Mon, Nov 21, 2011 at 1:10 PM, Hynek Cihlar <hynek.cihlar@gmail.com>wrote:
I send execute playback at time t0. I send execute break all also at time t0. Execute playback is queued in the channel queue. Execute break all is also queued in the channel queue. Channel thread picks up the execute playback, posts the execute notification, playback is queued for playback. Channel thread picks up the execute break all command...
Now, what is the particular reason that channel thread cannot stop the initiated playback?
Having to wait for the execute notification to be able to stop the playback makes the esl protocol unnecessary complicated. It's like having to wait for a TV to come up to be able to turn it off.
Sent from my mobile device
On Nov 21, 2011, at 18:01, Anthony Minessale <anthony.minessale@gmail.com> wrote:
execute over event socket does the same thing as broadcast:
The channel is very busy, its doing I/O in a very critical loop in its own thread. You cannot simply gain access to it and make it start executing your application because then it would be doing it inside that other thread and possibly stopping it when it's supposed to be doing something else.
Instead the instruction is queued to the channel and the channel does periodic calls to see if it has any tasks to execute when its tolerable to perform such a task and also ensuring its carried out in it's own dedicated session thread.
From the time you send the command there is an expected latency until the command is actually executed. From your application you should send the command then wait until you receive the channel_execute corresponding to the desired command before continuing and having clearance to send the uuid_break.
On Sun, Nov 20, 2011 at 2:07 AM, Hynek Cihlar < <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com> wrote:
So why would the bgapi uuid_break all fail if it queues the same way as execute does?
Hynek
On Sun, Nov 20, 2011 at 4:27 AM, Anthony Minessale <<anthony.minessale@gmail.com> anthony.minessale@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@gmail.com> hynek.cihlar@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@visionutveckling.se> peter.olsson@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@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org [<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org] för Hynek Cihlar [<hynek.cihlar@gmail.com> hynek.cihlar@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@visionutveckling.se> peter.olsson@visionutveckling.se<mailto:<peter.olsson@visionutveckling.se> peter.olsson@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> 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@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org> [<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org>] för Hynek Cihlar [ <hynek.cihlar@gmail.com>hynek.cihlar@gmail.com<mailto:<hynek.cihlar@gmail.com> hynek.cihlar@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@visionutveckling.se> peter.olsson@visionutveckling.se<mailto:<peter.olsson@visionutveckling.se> peter.olsson@visionutveckling.se><mailto:<peter.olsson@visionutveckling.se> peter.olsson@visionutveckling.se<mailto:<peter.olsson@visionutveckling.se> peter.olsson@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@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org><mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org>> [<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org><mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org>>] för Hynek Cihlar [ <hynek.cihlar@gmail.com>hynek.cihlar@gmail.com<mailto:<hynek.cihlar@gmail.com> hynek.cihlar@gmail.com><mailto: <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com> hynek.cihlar@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@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com><mailto: <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com>><mailto: <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com><mailto: <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com> hynek.cihlar@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@freeswitch.org>consulting@freeswitch.org<mailto:<consulting@freeswitch.org> consulting@freeswitch.org><mailto: <consulting@freeswitch.org> consulting@freeswitch.org<mailto: <consulting@freeswitch.org> consulting@freeswitch.org>> <http://www.freeswitchsolutions.com> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com>http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org>http://www.freeswitch.org <http://wiki.freeswitch.org>http://wiki.freeswitch.org <http://www.cluecon.com>http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org<mailto:<FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org><mailto:<FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org<mailto:<FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org>> <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org>http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org>consulting@freeswitch.org<mailto:<consulting@freeswitch.org> consulting@freeswitch.org> <http://www.freeswitchsolutions.com> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com>http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org>http://www.freeswitch.org <http://wiki.freeswitch.org>http://wiki.freeswitch.org <http://www.cluecon.com>http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org<mailto:<FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org> <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org>http://www.freeswitch.org
!DSPAM:4ec770ca32761488716642!
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org>consulting@freeswitch.org <http://www.freeswitchsolutions.com> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com>http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org>http://www.freeswitch.org <http://wiki.freeswitch.org>http://wiki.freeswitch.org <http://www.cluecon.com>http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org>http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org>consulting@freeswitch.org <http://www.freeswitchsolutions.com>http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com>http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org>http://www.freeswitch.org <http://wiki.freeswitch.org>http://wiki.freeswitch.org <http://www.cluecon.com>http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org>http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH <http://www.freeswitch.org/>http://www.freeswitch.org/ ClueCon <http://www.cluecon.com/>http://www.cluecon.com/ Twitter: <http://twitter.com/FreeSWITCH_wire> http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: <http://irc.freenode.net>irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip: <sip%3A888@conference.freeswitch.org>888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org>consulting@freeswitch.org <http://www.freeswitchsolutions.com>http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com>http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org>http://www.freeswitch.org <http://wiki.freeswitch.org>http://wiki.freeswitch.org <http://www.cluecon.com>http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org>http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org>consulting@freeswitch.org <http://www.freeswitchsolutions.com>http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com>http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org>http://www.freeswitch.org <http://wiki.freeswitch.org>http://wiki.freeswitch.org <http://www.cluecon.com>http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org>http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH <http://www.freeswitch.org/>http://www.freeswitch.org/ ClueCon <http://www.cluecon.com/>http://www.cluecon.com/ Twitter: <http://twitter.com/FreeSWITCH_wire> http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: <http://irc.freenode.net>irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip: <sip%3A888@conference.freeswitch.org>888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
I really didn't mean to be arrogant. The analogy was just to simplify the communication and express my concerns with the protocol, without the thorough understanding I don't think I can put together a serious esl app. I guess I will have to dive into the source code now and try to figure out by myself. Thank you for your inputs! Sent from my mobile device On Nov 22, 2011, at 0:30, Anthony Minessale <anthony.minessale@gmail.com> wrote: Your tone has changed to be unsatisfactorily arrogant to warrant my attention. Please refrain from any more disrespectful analogies. It would be like you came to a free forum to get help on a free software then questioned the response from the guy who designed it..... oh wait that's not an analogy that's what you are doing! If you sent sendevent with execute to send the playback then sent another one to execute break all (Assuming you did not have event_lock header which will force it to execute each instruction one at a time) it would indeed execute in order. You asked about using broadcast and uuid_break (broadcast is the same as sendmsg + execute) uuid_break is instant real time call so if you broadcast then uuid_break the break will easily beat the queuing. BTW I have 3 TV in my house all of which require you to wait for them to come all the way up to shut them back down. On Mon, Nov 21, 2011 at 1:10 PM, Hynek Cihlar <hynek.cihlar@gmail.com>wrote:
I send execute playback at time t0. I send execute break all also at time t0. Execute playback is queued in the channel queue. Execute break all is also queued in the channel queue. Channel thread picks up the execute playback, posts the execute notification, playback is queued for playback. Channel thread picks up the execute break all command...
Now, what is the particular reason that channel thread cannot stop the initiated playback?
Having to wait for the execute notification to be able to stop the playback makes the esl protocol unnecessary complicated. It's like having to wait for a TV to come up to be able to turn it off.
Sent from my mobile device
On Nov 21, 2011, at 18:01, Anthony Minessale <anthony.minessale@gmail.com> wrote:
execute over event socket does the same thing as broadcast:
The channel is very busy, its doing I/O in a very critical loop in its own thread. You cannot simply gain access to it and make it start executing your application because then it would be doing it inside that other thread and possibly stopping it when it's supposed to be doing something else.
Instead the instruction is queued to the channel and the channel does periodic calls to see if it has any tasks to execute when its tolerable to perform such a task and also ensuring its carried out in it's own dedicated session thread.
From the time you send the command there is an expected latency until the command is actually executed. From your application you should send the command then wait until you receive the channel_execute corresponding to the desired command before continuing and having clearance to send the uuid_break.
On Sun, Nov 20, 2011 at 2:07 AM, Hynek Cihlar < <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com> wrote:
So why would the bgapi uuid_break all fail if it queues the same way as execute does?
Hynek
On Sun, Nov 20, 2011 at 4:27 AM, Anthony Minessale <<anthony.minessale@gmail.com> anthony.minessale@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@gmail.com> hynek.cihlar@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@visionutveckling.se> peter.olsson@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@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org [<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org] för Hynek Cihlar [<hynek.cihlar@gmail.com> hynek.cihlar@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@visionutveckling.se> peter.olsson@visionutveckling.se<mailto:<peter.olsson@visionutveckling.se> peter.olsson@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> 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@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org> [<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org>] för Hynek Cihlar [ <hynek.cihlar@gmail.com>hynek.cihlar@gmail.com<mailto:<hynek.cihlar@gmail.com> hynek.cihlar@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@visionutveckling.se> peter.olsson@visionutveckling.se<mailto:<peter.olsson@visionutveckling.se> peter.olsson@visionutveckling.se><mailto:<peter.olsson@visionutveckling.se> peter.olsson@visionutveckling.se<mailto:<peter.olsson@visionutveckling.se> peter.olsson@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@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org><mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org>> [<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org><mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org>>] för Hynek Cihlar [ <hynek.cihlar@gmail.com>hynek.cihlar@gmail.com<mailto:<hynek.cihlar@gmail.com> hynek.cihlar@gmail.com><mailto: <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com> hynek.cihlar@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@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com><mailto: <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com>><mailto: <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com><mailto: <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com> hynek.cihlar@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@freeswitch.org>consulting@freeswitch.org<mailto:<consulting@freeswitch.org> consulting@freeswitch.org><mailto: <consulting@freeswitch.org> consulting@freeswitch.org<mailto: <consulting@freeswitch.org> consulting@freeswitch.org>> <http://www.freeswitchsolutions.com> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com>http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org>http://www.freeswitch.org <http://wiki.freeswitch.org>http://wiki.freeswitch.org <http://www.cluecon.com>http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org<mailto:<FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org><mailto:<FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org<mailto:<FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org>> <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org>http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org>consulting@freeswitch.org<mailto:<consulting@freeswitch.org> consulting@freeswitch.org> <http://www.freeswitchsolutions.com> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com>http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org>http://www.freeswitch.org <http://wiki.freeswitch.org>http://wiki.freeswitch.org <http://www.cluecon.com>http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org<mailto:<FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org> <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org>http://www.freeswitch.org
!DSPAM:4ec770ca32761488716642!
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org>consulting@freeswitch.org <http://www.freeswitchsolutions.com> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com>http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org>http://www.freeswitch.org <http://wiki.freeswitch.org>http://wiki.freeswitch.org <http://www.cluecon.com>http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org>http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org>consulting@freeswitch.org <http://www.freeswitchsolutions.com>http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com>http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org>http://www.freeswitch.org <http://wiki.freeswitch.org>http://wiki.freeswitch.org <http://www.cluecon.com>http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org>http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH <http://www.freeswitch.org/>http://www.freeswitch.org/ ClueCon <http://www.cluecon.com/>http://www.cluecon.com/ Twitter: <http://twitter.com/FreeSWITCH_wire> http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: <http://irc.freenode.net>irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip: <sip%3A888@conference.freeswitch.org>888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org>consulting@freeswitch.org <http://www.freeswitchsolutions.com>http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com>http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org>http://www.freeswitch.org <http://wiki.freeswitch.org>http://wiki.freeswitch.org <http://www.cluecon.com>http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org>http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org>consulting@freeswitch.org <http://www.freeswitchsolutions.com>http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com>http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org>http://www.freeswitch.org <http://wiki.freeswitch.org>http://wiki.freeswitch.org <http://www.cluecon.com>http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org>http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH <http://www.freeswitch.org/>http://www.freeswitch.org/ ClueCon <http://www.cluecon.com/>http://www.cluecon.com/ Twitter: <http://twitter.com/FreeSWITCH_wire> http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: <http://irc.freenode.net>irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip: <sip%3A888@conference.freeswitch.org>888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org pstn:+19193869900 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I just explained it to you for what it's worth. On Mon, Nov 21, 2011 at 10:53 PM, Hynek Cihlar <hynek.cihlar@gmail.com>wrote:
I really didn't mean to be arrogant. The analogy was just to simplify the communication and express my concerns with the protocol, without the thorough understanding I don't think I can put together a serious esl app.
I guess I will have to dive into the source code now and try to figure out by myself.
Thank you for your inputs!
Sent from my mobile device
On Nov 22, 2011, at 0:30, Anthony Minessale <anthony.minessale@gmail.com> wrote:
Your tone has changed to be unsatisfactorily arrogant to warrant my attention. Please refrain from any more disrespectful analogies. It would be like you came to a free forum to get help on a free software then questioned the response from the guy who designed it..... oh wait that's not an analogy that's what you are doing!
If you sent sendevent with execute to send the playback then sent another one to execute break all (Assuming you did not have event_lock header which will force it to execute each instruction one at a time) it would indeed execute in order.
You asked about using broadcast and uuid_break (broadcast is the same as sendmsg + execute) uuid_break is instant real time call so if you broadcast then uuid_break the break will easily beat the queuing.
BTW I have 3 TV in my house all of which require you to wait for them to come all the way up to shut them back down.
On Mon, Nov 21, 2011 at 1:10 PM, Hynek Cihlar < <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com> wrote:
I send execute playback at time t0. I send execute break all also at time t0. Execute playback is queued in the channel queue. Execute break all is also queued in the channel queue. Channel thread picks up the execute playback, posts the execute notification, playback is queued for playback. Channel thread picks up the execute break all command...
Now, what is the particular reason that channel thread cannot stop the initiated playback?
Having to wait for the execute notification to be able to stop the playback makes the esl protocol unnecessary complicated. It's like having to wait for a TV to come up to be able to turn it off.
Sent from my mobile device
On Nov 21, 2011, at 18:01, Anthony Minessale <<anthony.minessale@gmail.com> anthony.minessale@gmail.com> wrote:
execute over event socket does the same thing as broadcast:
The channel is very busy, its doing I/O in a very critical loop in its own thread. You cannot simply gain access to it and make it start executing your application because then it would be doing it inside that other thread and possibly stopping it when it's supposed to be doing something else.
Instead the instruction is queued to the channel and the channel does periodic calls to see if it has any tasks to execute when its tolerable to perform such a task and also ensuring its carried out in it's own dedicated session thread.
From the time you send the command there is an expected latency until the command is actually executed. From your application you should send the command then wait until you receive the channel_execute corresponding to the desired command before continuing and having clearance to send the uuid_break.
On Sun, Nov 20, 2011 at 2:07 AM, Hynek Cihlar < <hynek.cihlar@gmail.com><hynek.cihlar@gmail.com> hynek.cihlar@gmail.com> wrote:
So why would the bgapi uuid_break all fail if it queues the same way as execute does?
Hynek
On Sun, Nov 20, 2011 at 4:27 AM, Anthony Minessale <<anthony.minessale@gmail.com><anthony.minessale@gmail.com> anthony.minessale@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@gmail.com><hynek.cihlar@gmail.com> hynek.cihlar@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@visionutveckling.se><peter.olsson@visionutveckling.se> peter.olsson@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@lists.freeswitch.org><freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org [<freeswitch-users-bounces@lists.freeswitch.org><freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org] för Hynek Cihlar [ <hynek.cihlar@gmail.com> <hynek.cihlar@gmail.com> hynek.cihlar@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@visionutveckling.se><peter.olsson@visionutveckling.se> peter.olsson@visionutveckling.se<mailto:<peter.olsson@visionutveckling.se><peter.olsson@visionutveckling.se> peter.olsson@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><http://wiki.freeswitch.org/wiki/Mod_event_socket#execute> 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@lists.freeswitch.org><freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org><freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org> [<freeswitch-users-bounces@lists.freeswitch.org><freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org><freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org>] för Hynek Cihlar [ <hynek.cihlar@gmail.com> <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com><hynek.cihlar@gmail.com> hynek.cihlar@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@visionutveckling.se><peter.olsson@visionutveckling.se> peter.olsson@visionutveckling.se<mailto:<peter.olsson@visionutveckling.se><peter.olsson@visionutveckling.se> peter.olsson@visionutveckling.se><mailto:<peter.olsson@visionutveckling.se><peter.olsson@visionutveckling.se> peter.olsson@visionutveckling.se<mailto:<peter.olsson@visionutveckling.se><peter.olsson@visionutveckling.se> peter.olsson@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@lists.freeswitch.org><freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org><freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org><mailto:<freeswitch-users-bounces@lists.freeswitch.org><freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org><freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org>> [<freeswitch-users-bounces@lists.freeswitch.org><freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org><freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org><mailto:<freeswitch-users-bounces@lists.freeswitch.org><freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org<mailto:<freeswitch-users-bounces@lists.freeswitch.org><freeswitch-users-bounces@lists.freeswitch.org> freeswitch-users-bounces@lists.freeswitch.org>>] för Hynek Cihlar [ <hynek.cihlar@gmail.com> <hynek.cihlar@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com><hynek.cihlar@gmail.com> hynek.cihlar@gmail.com><mailto: <hynek.cihlar@gmail.com><hynek.cihlar@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com><hynek.cihlar@gmail.com> hynek.cihlar@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@gmail.com><hynek.cihlar@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com><hynek.cihlar@gmail.com> hynek.cihlar@gmail.com><mailto: <hynek.cihlar@gmail.com><hynek.cihlar@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com><hynek.cihlar@gmail.com> hynek.cihlar@gmail.com>><mailto: <hynek.cihlar@gmail.com><hynek.cihlar@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com><hynek.cihlar@gmail.com> hynek.cihlar@gmail.com><mailto: <hynek.cihlar@gmail.com><hynek.cihlar@gmail.com> hynek.cihlar@gmail.com<mailto: <hynek.cihlar@gmail.com><hynek.cihlar@gmail.com> hynek.cihlar@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@freeswitch.org> <consulting@freeswitch.org> consulting@freeswitch.org<mailto: <consulting@freeswitch.org><consulting@freeswitch.org> consulting@freeswitch.org><mailto: <consulting@freeswitch.org><consulting@freeswitch.org> consulting@freeswitch.org<mailto: <consulting@freeswitch.org><consulting@freeswitch.org> consulting@freeswitch.org>> <http://www.freeswitchsolutions.com><http://www.freeswitchsolutions.com> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com> <http://www.cudatel.com> http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org> <http://www.freeswitch.org> http://www.freeswitch.org <http://wiki.freeswitch.org> <http://wiki.freeswitch.org> http://wiki.freeswitch.org <http://www.cluecon.com> <http://www.cluecon.com> http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org><FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org<mailto:<FreeSWITCH-users@lists.freeswitch.org><FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org><mailto:<FreeSWITCH-users@lists.freeswitch.org><FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org<mailto:<FreeSWITCH-users@lists.freeswitch.org><FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org>> <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users><http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users><http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org> <http://www.freeswitch.org> http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org> <consulting@freeswitch.org> consulting@freeswitch.org<mailto: <consulting@freeswitch.org><consulting@freeswitch.org> consulting@freeswitch.org> <http://www.freeswitchsolutions.com><http://www.freeswitchsolutions.com> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com> <http://www.cudatel.com> http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org> <http://www.freeswitch.org> http://www.freeswitch.org <http://wiki.freeswitch.org> <http://wiki.freeswitch.org> http://wiki.freeswitch.org <http://www.cluecon.com> <http://www.cluecon.com> http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org><FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org<mailto:<FreeSWITCH-users@lists.freeswitch.org><FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org> <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users><http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users><http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org> <http://www.freeswitch.org> http://www.freeswitch.org
!DSPAM:4ec770ca32761488716642!
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org> <consulting@freeswitch.org> consulting@freeswitch.org <http://www.freeswitchsolutions.com><http://www.freeswitchsolutions.com> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com> <http://www.cudatel.com> http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org> <http://www.freeswitch.org> http://www.freeswitch.org <http://wiki.freeswitch.org> <http://wiki.freeswitch.org> http://wiki.freeswitch.org <http://www.cluecon.com> <http://www.cluecon.com> http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org><FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users><http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users><http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org> <http://www.freeswitch.org> http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org> <consulting@freeswitch.org> consulting@freeswitch.org <http://www.freeswitchsolutions.com><http://www.freeswitchsolutions.com> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com> <http://www.cudatel.com> http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org> <http://www.freeswitch.org> http://www.freeswitch.org <http://wiki.freeswitch.org> <http://wiki.freeswitch.org> http://wiki.freeswitch.org <http://www.cluecon.com> <http://www.cluecon.com> http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org><FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users><http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users><http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org> <http://www.freeswitch.org> http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH <http://www.freeswitch.org/> <http://www.freeswitch.org/> http://www.freeswitch.org/ ClueCon <http://www.cluecon.com/> <http://www.cluecon.com/> http://www.cluecon.com/ Twitter: <http://twitter.com/FreeSWITCH_wire><http://twitter.com/FreeSWITCH_wire> http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: <http://irc.freenode.net> <http://irc.freenode.net> irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip: <sip%3A888@conference.freeswitch.org><888@conference.freeswitch.org> 888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org> <consulting@freeswitch.org> consulting@freeswitch.org <http://www.freeswitchsolutions.com><http://www.freeswitchsolutions.com> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com> <http://www.cudatel.com> http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org> <http://www.freeswitch.org> http://www.freeswitch.org <http://wiki.freeswitch.org> <http://wiki.freeswitch.org> http://wiki.freeswitch.org <http://www.cluecon.com> <http://www.cluecon.com> http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org><FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users><http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users><http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org> <http://www.freeswitch.org> http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org> <consulting@freeswitch.org> consulting@freeswitch.org <http://www.freeswitchsolutions.com><http://www.freeswitchsolutions.com> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com> <http://www.cudatel.com>http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org> <http://www.freeswitch.org> http://www.freeswitch.org <http://wiki.freeswitch.org> <http://wiki.freeswitch.org> http://wiki.freeswitch.org <http://www.cluecon.com> <http://www.cluecon.com>http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org><FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users><http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users><http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org> <http://www.freeswitch.org> http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH <http://www.freeswitch.org/> <http://www.freeswitch.org/> http://www.freeswitch.org/ ClueCon <http://www.cluecon.com/> <http://www.cluecon.com/> http://www.cluecon.com/ Twitter: <http://twitter.com/FreeSWITCH_wire><http://twitter.com/FreeSWITCH_wire> http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: <http://irc.freenode.net> <http://irc.freenode.net>irc.freenode.net#freeswitch
FreeSWITCH Developer Conference sip: <sip%3A888@conference.freeswitch.org><888@conference.freeswitch.org> 888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org>consulting@freeswitch.org <http://www.freeswitchsolutions.com>http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com>http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org>http://www.freeswitch.org <http://wiki.freeswitch.org>http://wiki.freeswitch.org <http://www.cluecon.com>http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org>http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: <consulting@freeswitch.org>consulting@freeswitch.org <http://www.freeswitchsolutions.com>http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server <http://www.cudatel.com>http://www.cudatel.com
Official FreeSWITCH Sites <http://www.freeswitch.org>http://www.freeswitch.org <http://wiki.freeswitch.org>http://wiki.freeswitch.org <http://www.cluecon.com>http://www.cluecon.com
FreeSWITCH-users mailing list <FreeSWITCH-users@lists.freeswitch.org> FreeSWITCH-users@lists.freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:<http://lists.freeswitch.org/mailman/options/freeswitch-users> http://lists.freeswitch.org/mailman/options/freeswitch-users <http://www.freeswitch.org>http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH <http://www.freeswitch.org/>http://www.freeswitch.org/ ClueCon <http://www.cluecon.com/>http://www.cluecon.com/ Twitter: <http://twitter.com/FreeSWITCH_wire> http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: <http://irc.freenode.net>irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip: <sip%3A888@conference.freeswitch.org>888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Hello, Following the instructions in http://wiki.freeswitch.org/wiki/Embedding_FreeSWITCH I am trying to use Embedded FreeSwitch. I installed FS in Fedora linux as a root user in /usr/local/freeswitch. Now as non-root user, I compiled following codes: #include <switch.h> int main(int argc, char** argv) { switch_core_flag_t flags = SCF_USE_SQL; bool console = true; const char *err = NULL; switch_core_set_globals(); switch_core_init_and_modload(flags, console ? SWITCH_TRUE : SWITCH_FALSE, &err); switch_core_runtime_loop(!console); return 0; } And copy the executable and conf, mod, contents of lib of the installed FS to my $MyWorkingDir. My directory structure looks like: MyWorkingDir--bin/ (contains my executable: FS_Embed) --conf/ --mod/ --lib/ --grammars --sounds --scripts --log (I also tried to copy the contents of lib directory into MyWorkingDir) When I run my embedded FS: ./FS_Embed, I got error 2011-11-21 18:46:26.606783 [INFO] switch_event.c:631 Activate Eventing Engine. 2011-11-21 18:46:26.617941 [DEBUG] switch_event.c:610 Create event dispatch thread 0 FS_Embed: src/switch_xml.c:2225: switch_xml_open_cfg: Assertion `MAIN_XML_ROOT != ((void *)0)' failed. Aborted (core dumped) and occasionally on another run, I got error: 2011-11-21 16:56:51.756040 [INFO] switch_event.c:631 Activate Eventing Engine. 2011-11-21 16:56:51.767198 [DEBUG] switch_event.c:610 Create event dispatch thread 0 Segmentation fault (core dumped) It looks like there are some things wrong with my Environment Setup for Embedded FS, but after a while of checking/trying/googling I couldn't find what's wrong. Any advice please? Many thanks! Xing -- Heriot-Watt University is a Scottish charity registered under charity number SC000278. Heriot-Watt University is the Sunday Times Scottish University of the Year 2011-2012
try if (apr_initialize() != SWITCH_STATUS_SUCCESS) { fprintf(stderr, "FATAL ERROR! Could not initialize APR\n"); return 255; } early on in main() On Mon, Nov 21, 2011 at 1:12 PM, xl127 <x.liu@hw.ac.uk> wrote:
Hello,
Following the instructions in http://wiki.freeswitch.org/wiki/Embedding_FreeSWITCH I am trying to use Embedded FreeSwitch.
I installed FS in Fedora linux as a root user in /usr/local/freeswitch. Now as non-root user, I compiled following codes:
#include <switch.h> int main(int argc, char** argv) { switch_core_flag_t flags = SCF_USE_SQL; bool console = true; const char *err = NULL; switch_core_set_globals(); switch_core_init_and_modload(flags, console ? SWITCH_TRUE : SWITCH_FALSE, &err); switch_core_runtime_loop(!console); return 0; }
And copy the executable and conf, mod, contents of lib of the installed FS to my $MyWorkingDir.
My directory structure looks like: MyWorkingDir--bin/ (contains my executable: FS_Embed) --conf/ --mod/ --lib/ --grammars --sounds --scripts --log (I also tried to copy the contents of lib directory into MyWorkingDir)
When I run my embedded FS: ./FS_Embed, I got error
2011-11-21 18:46:26.606783 [INFO] switch_event.c:631 Activate Eventing Engine. 2011-11-21 18:46:26.617941 [DEBUG] switch_event.c:610 Create event dispatch thread 0 FS_Embed: src/switch_xml.c:2225: switch_xml_open_cfg: Assertion `MAIN_XML_ROOT != ((void *)0)' failed. Aborted (core dumped)
and occasionally on another run, I got error:
2011-11-21 16:56:51.756040 [INFO] switch_event.c:631 Activate Eventing Engine. 2011-11-21 16:56:51.767198 [DEBUG] switch_event.c:610 Create event dispatch thread 0 Segmentation fault (core dumped)
It looks like there are some things wrong with my Environment Setup for Embedded FS, but after a while of checking/trying/googling I couldn't find what's wrong.
Any advice please?
Many thanks! Xing
-- Heriot-Watt University is a Scottish charity registered under charity number SC000278.
Heriot-Watt University is the Sunday Times Scottish University of the Year 2011-2012
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Thanks for the advice! I tried it but still got the same error. I added the #include <apr_general.h> and found it from /usr/local/sr/freeswitch/libs/apr/include rather than from the installed directory /usr/local/freeswitch. Hope it is the right one. any more clues? On 22/11/11 01:38, Anthony Minessale wrote:
try
if (apr_initialize() != SWITCH_STATUS_SUCCESS) { fprintf(stderr, "FATAL ERROR! Could not initialize APR\n"); return 255; }
early on in main()
On Mon, Nov 21, 2011 at 1:12 PM, xl127 <x.liu@hw.ac.uk <mailto:x.liu@hw.ac.uk>> wrote:
Hello,
Following the instructions in http://wiki.freeswitch.org/wiki/Embedding_FreeSWITCH I am trying to use Embedded FreeSwitch.
I installed FS in Fedora linux as a root user in /usr/local/freeswitch. Now as non-root user, I compiled following codes:
#include <switch.h> int main(int argc, char** argv) { switch_core_flag_t flags = SCF_USE_SQL; bool console = true; const char *err = NULL; switch_core_set_globals(); switch_core_init_and_modload(flags, console ? SWITCH_TRUE : SWITCH_FALSE, &err); switch_core_runtime_loop(!console); return 0; }
And copy the executable and conf, mod, contents of lib of the installed FS to my $MyWorkingDir.
My directory structure looks like: MyWorkingDir--bin/ (contains my executable: FS_Embed) --conf/ --mod/ --lib/ --grammars --sounds --scripts --log (I also tried to copy the contents of lib directory into MyWorkingDir)
When I run my embedded FS: ./FS_Embed, I got error
2011-11-21 18:46:26.606783 [INFO] switch_event.c:631 Activate Eventing Engine. 2011-11-21 18:46:26.617941 [DEBUG] switch_event.c:610 Create event dispatch thread 0 FS_Embed: src/switch_xml.c:2225: switch_xml_open_cfg: Assertion `MAIN_XML_ROOT != ((void *)0)' failed. Aborted (core dumped)
and occasionally on another run, I got error:
2011-11-21 16:56:51.756040 [INFO] switch_event.c:631 Activate Eventing Engine. 2011-11-21 16:56:51.767198 [DEBUG] switch_event.c:610 Create event dispatch thread 0 Segmentation fault (core dumped)
It looks like there are some things wrong with my Environment Setup for Embedded FS, but after a while of checking/trying/googling I couldn't find what's wrong.
Any advice please?
Many thanks! Xing
-- Heriot-Watt University is a Scottish charity registered under charity number SC000278.
Heriot-Watt University is the Sunday Times Scottish University of the Year 2011-2012
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@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@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Heriot-Watt University is a Scottish charity registered under charity number SC000278. Heriot-Watt University is the Sunday Times Scottish University of the Year 2011-2012
i know you needed apr, not sure, maybe try strace or gdb On Tue, Nov 22, 2011 at 6:36 AM, xl127 <x.liu@hw.ac.uk> wrote:
Thanks for the advice!
I tried it but still got the same error.
I added the #include <apr_general.h> and found it from /usr/local/sr/freeswitch/libs/apr/include rather than from the installed directory /usr/local/freeswitch. Hope it is the right one.
any more clues?
On 22/11/11 01:38, Anthony Minessale wrote:
try
if (apr_initialize() != SWITCH_STATUS_SUCCESS) { fprintf(stderr, "FATAL ERROR! Could not initialize APR\n"); return 255; }
early on in main()
On Mon, Nov 21, 2011 at 1:12 PM, xl127 <x.liu@hw.ac.uk> wrote:
Hello,
Following the instructions in http://wiki.freeswitch.org/wiki/Embedding_FreeSWITCH I am trying to use Embedded FreeSwitch.
I installed FS in Fedora linux as a root user in /usr/local/freeswitch. Now as non-root user, I compiled following codes:
#include <switch.h> int main(int argc, char** argv) { switch_core_flag_t flags = SCF_USE_SQL; bool console = true; const char *err = NULL; switch_core_set_globals(); switch_core_init_and_modload(flags, console ? SWITCH_TRUE : SWITCH_FALSE, &err); switch_core_runtime_loop(!console); return 0; }
And copy the executable and conf, mod, contents of lib of the installed FS to my $MyWorkingDir.
My directory structure looks like: MyWorkingDir--bin/ (contains my executable: FS_Embed) --conf/ --mod/ --lib/ --grammars --sounds --scripts --log (I also tried to copy the contents of lib directory into MyWorkingDir)
When I run my embedded FS: ./FS_Embed, I got error
2011-11-21 18:46:26.606783 [INFO] switch_event.c:631 Activate Eventing Engine. 2011-11-21 18:46:26.617941 [DEBUG] switch_event.c:610 Create event dispatch thread 0 FS_Embed: src/switch_xml.c:2225: switch_xml_open_cfg: Assertion `MAIN_XML_ROOT != ((void *)0)' failed. Aborted (core dumped)
and occasionally on another run, I got error:
2011-11-21 16:56:51.756040 [INFO] switch_event.c:631 Activate Eventing Engine. 2011-11-21 16:56:51.767198 [DEBUG] switch_event.c:610 Create event dispatch thread 0 Segmentation fault (core dumped)
It looks like there are some things wrong with my Environment Setup for Embedded FS, but after a while of checking/trying/googling I couldn't find what's wrong.
Any advice please?
Many thanks! Xing
-- Heriot-Watt University is a Scottish charity registered under charity number SC000278.
Heriot-Watt University is the Sunday Times Scottish University of the Year 2011-2012
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
------------------------------
[image: MailScanner Signature HW] *Heriot-Watt University is the Sunday Times
Scottish University of the Year 2011-2012 *
Heriot-Watt University is a Scottish charity registered under charity number SC000278.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
If I switch to root user I can successfully run my embedded FS app: FS_Embed. but it will fails if I run it as non-root user. One thing I can think of to do is re-install FS as non-root. I tried but it failed to access /usr/lib/python2.7/site-packages/freeswitch.py due to the permissions. On 22/11/11 16:08, Anthony Minessale wrote:
i know you needed apr, not sure, maybe try strace or gdb
On Tue, Nov 22, 2011 at 6:36 AM, xl127 <x.liu@hw.ac.uk <mailto:x.liu@hw.ac.uk>> wrote:
Thanks for the advice!
I tried it but still got the same error.
I added the #include <apr_general.h> and found it from /usr/local/sr/freeswitch/libs/apr/include rather than from the installed directory /usr/local/freeswitch. Hope it is the right one.
any more clues?
On 22/11/11 01:38, Anthony Minessale wrote:
try
if (apr_initialize() != SWITCH_STATUS_SUCCESS) { fprintf(stderr, "FATAL ERROR! Could not initialize APR\n"); return 255; }
early on in main()
On Mon, Nov 21, 2011 at 1:12 PM, xl127 <x.liu@hw.ac.uk <mailto:x.liu@hw.ac.uk>> wrote:
Hello,
Following the instructions in http://wiki.freeswitch.org/wiki/Embedding_FreeSWITCH I am trying to use Embedded FreeSwitch.
I installed FS in Fedora linux as a root user in /usr/local/freeswitch. Now as non-root user, I compiled following codes:
#include <switch.h> int main(int argc, char** argv) { switch_core_flag_t flags = SCF_USE_SQL; bool console = true; const char *err = NULL; switch_core_set_globals(); switch_core_init_and_modload(flags, console ? SWITCH_TRUE : SWITCH_FALSE, &err); switch_core_runtime_loop(!console); return 0; }
And copy the executable and conf, mod, contents of lib of the installed FS to my $MyWorkingDir.
My directory structure looks like: MyWorkingDir--bin/ (contains my executable: FS_Embed) --conf/ --mod/ --lib/ --grammars --sounds --scripts --log (I also tried to copy the contents of lib directory into MyWorkingDir)
When I run my embedded FS: ./FS_Embed, I got error
2011-11-21 18:46:26.606783 [INFO] switch_event.c:631 Activate Eventing Engine. 2011-11-21 18:46:26.617941 [DEBUG] switch_event.c:610 Create event dispatch thread 0 FS_Embed: src/switch_xml.c:2225: switch_xml_open_cfg: Assertion `MAIN_XML_ROOT != ((void *)0)' failed. Aborted (core dumped)
and occasionally on another run, I got error:
2011-11-21 16:56:51.756040 [INFO] switch_event.c:631 Activate Eventing Engine. 2011-11-21 16:56:51.767198 [DEBUG] switch_event.c:610 Create event dispatch thread 0 Segmentation fault (core dumped)
It looks like there are some things wrong with my Environment Setup for Embedded FS, but after a while of checking/trying/googling I couldn't find what's wrong.
Any advice please?
Many thanks! Xing
-- Heriot-Watt University is a Scottish charity registered under charity number SC000278.
Heriot-Watt University is the Sunday Times Scottish University of the Year 2011-2012
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@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@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900 <tel:%2B19193869900>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
------------------------------------------------------------------------
MailScanner Signature HW *Heriot-Watt University is the Sunday Times
Scottish University of the Year 2011-2012 *
Heriot-Watt University is a Scottish charity registered under charity number SC000278.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@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@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Heriot-Watt University is a Scottish charity registered under charity number SC000278. Heriot-Watt University is the Sunday Times Scottish University of the Year 2011-2012
maybe your user does not have permissions to read and write the target install dir try to chown -R to your user on all of /usr/local/freeswitch you might want to try things the other way around and embedd your app in FS rather than embed FS in your app. On Tue, Nov 22, 2011 at 10:20 AM, xl127 <x.liu@hw.ac.uk> wrote:
If I switch to root user I can successfully run my embedded FS app: FS_Embed. but it will fails if I run it as non-root user.
One thing I can think of to do is re-install FS as non-root. I tried but it failed to access /usr/lib/python2.7/site-packages/freeswitch.py due to the permissions.
On 22/11/11 16:08, Anthony Minessale wrote:
i know you needed apr, not sure, maybe try strace or gdb
On Tue, Nov 22, 2011 at 6:36 AM, xl127 <x.liu@hw.ac.uk> wrote:
Thanks for the advice!
I tried it but still got the same error.
I added the #include <apr_general.h> and found it from /usr/local/sr/freeswitch/libs/apr/include rather than from the installed directory /usr/local/freeswitch. Hope it is the right one.
any more clues?
On 22/11/11 01:38, Anthony Minessale wrote:
try
if (apr_initialize() != SWITCH_STATUS_SUCCESS) { fprintf(stderr, "FATAL ERROR! Could not initialize APR\n"); return 255; }
early on in main()
On Mon, Nov 21, 2011 at 1:12 PM, xl127 <x.liu@hw.ac.uk> wrote:
Hello,
Following the instructions in http://wiki.freeswitch.org/wiki/Embedding_FreeSWITCH I am trying to use Embedded FreeSwitch.
I installed FS in Fedora linux as a root user in /usr/local/freeswitch. Now as non-root user, I compiled following codes:
#include <switch.h> int main(int argc, char** argv) { switch_core_flag_t flags = SCF_USE_SQL; bool console = true; const char *err = NULL; switch_core_set_globals(); switch_core_init_and_modload(flags, console ? SWITCH_TRUE : SWITCH_FALSE, &err); switch_core_runtime_loop(!console); return 0; }
And copy the executable and conf, mod, contents of lib of the installed FS to my $MyWorkingDir.
My directory structure looks like: MyWorkingDir--bin/ (contains my executable: FS_Embed) --conf/ --mod/ --lib/ --grammars --sounds --scripts --log (I also tried to copy the contents of lib directory into MyWorkingDir)
When I run my embedded FS: ./FS_Embed, I got error
2011-11-21 18:46:26.606783 [INFO] switch_event.c:631 Activate Eventing Engine. 2011-11-21 18:46:26.617941 [DEBUG] switch_event.c:610 Create event dispatch thread 0 FS_Embed: src/switch_xml.c:2225: switch_xml_open_cfg: Assertion `MAIN_XML_ROOT != ((void *)0)' failed. Aborted (core dumped)
and occasionally on another run, I got error:
2011-11-21 16:56:51.756040 [INFO] switch_event.c:631 Activate Eventing Engine. 2011-11-21 16:56:51.767198 [DEBUG] switch_event.c:610 Create event dispatch thread 0 Segmentation fault (core dumped)
It looks like there are some things wrong with my Environment Setup for Embedded FS, but after a while of checking/trying/googling I couldn't find what's wrong.
Any advice please?
Many thanks! Xing
-- Heriot-Watt University is a Scottish charity registered under charity number SC000278.
Heriot-Watt University is the Sunday Times Scottish University of the Year 2011-2012
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
------------------------------
[image: MailScanner Signature HW] *Heriot-Watt University is the Sunday Times
Scottish University of the Year 2011-2012 *
Heriot-Watt University is a Scottish charity registered under charity number SC000278.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Serverhttp://www.cudatel.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://wiki.freeswitch.orghttp://www.cluecon.com
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
------------------------------
[image: MailScanner Signature HW] *Heriot-Watt University is the Sunday Times Scottish University of the Year 2011-2012*
Heriot-Watt University is a Scottish charity registered under charity number SC000278.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Hi, The problem has been solved. I report it back here in case it might be helpful to others who would run into similar problems. Basically I added switch_core_init(..) and set parameters for the global variable: SWITCH_GLOBAL_dirs Below are the working codes: ====================================================================== #include <iostream> #include <switch.h> #include <QDir> int main(int argc, char** argv) { switch_core_flag_t flags = SCF_USE_SQL; bool console = true; const char *err = NULL; switch_core_set_globals(); QDir conf_dir = QDir::current(); SWITCH_GLOBAL_dirs.conf_dir = (char *) malloc(strlen(QString("%1/conf").arg(conf_dir.absolutePath()).toAscii().constData()) + 1); if (!SWITCH_GLOBAL_dirs.conf_dir) { fprintf(stderr, "Cannot allocate memory for conf_dir."); } strcpy(SWITCH_GLOBAL_dirs.conf_dir, QString("%1/conf").arg(conf_dir.absolutePath()).toAscii().constData()); fprintf(stderr, "AAA%s\n",SWITCH_GLOBAL_dirs.conf_dir); SWITCH_GLOBAL_dirs.log_dir = (char *) malloc(strlen(QString("%1/log").arg(conf_dir.absolutePath()).toAscii().constData()) + 1); if (!SWITCH_GLOBAL_dirs.log_dir) { fprintf(stderr,"Cannot allocate memory for log_dir."); } strcpy(SWITCH_GLOBAL_dirs.log_dir, QString("%1/log").arg(conf_dir.absolutePath()).toAscii().constData()); SWITCH_GLOBAL_dirs.run_dir = (char *) malloc(strlen(QString("%1/run").arg(conf_dir.absolutePath()).toAscii().constData()) + 1); if (!SWITCH_GLOBAL_dirs.run_dir) { fprintf(stderr,"Cannot allocate memory for run_dir."); } strcpy(SWITCH_GLOBAL_dirs.run_dir, QString("%1/run").arg(conf_dir.absolutePath()).toAscii().constData()); SWITCH_GLOBAL_dirs.db_dir = (char *) malloc(strlen(QString("%1/db").arg(conf_dir.absolutePath()).toAscii().constData()) + 1); if (!SWITCH_GLOBAL_dirs.db_dir) { fprintf(stderr,"Cannot allocate memory for db_dir."); } strcpy(SWITCH_GLOBAL_dirs.db_dir, QString("%1/db").arg(conf_dir.absolutePath()).toAscii().constData()); SWITCH_GLOBAL_dirs.script_dir = (char *) malloc(strlen(QString("%1/script").arg(conf_dir.absolutePath()).toAscii().constData()) + 1); if (!SWITCH_GLOBAL_dirs.script_dir) { fprintf(stderr,"Cannot allocate memory for script_dir."); } strcpy(SWITCH_GLOBAL_dirs.script_dir, QString("%1/script").arg(conf_dir.absolutePath()).toAscii().constData()); SWITCH_GLOBAL_dirs.htdocs_dir = (char *) malloc(strlen(QString("%1/htdocs").arg(conf_dir.absolutePath()).toAscii().constData()) + 1); if (!SWITCH_GLOBAL_dirs.htdocs_dir) { fprintf(stderr,"Cannot allocate memory for htdocs_dir."); } strcpy(SWITCH_GLOBAL_dirs.htdocs_dir, QString("%1/htdocs").arg(conf_dir.absolutePath()).toAscii().constData()); SWITCH_GLOBAL_dirs.grammar_dir = (char *) malloc(strlen(QString("%1/grammar").arg(conf_dir.absolutePath()).toAscii().constData()) + 1); if (!SWITCH_GLOBAL_dirs.grammar_dir) { fprintf(stderr,"Cannot allocate memory for grammar_dir."); } strcpy(SWITCH_GLOBAL_dirs.grammar_dir, QString("%1/grammar").arg(conf_dir.absolutePath()).toAscii().constData()); /* Initialize the core and load modules, that will startup FS completely */ //if (switch_core_init(flags, console, &err) != SWITCH_STATUS_SUCCESS) { if (switch_core_init(flags, console ? SWITCH_TRUE : SWITCH_FALSE, &err) != SWITCH_STATUS_SUCCESS) { fprintf(stderr, "Failed to initialize FreeSWITCH's core: %s\n", err); } //switch_core_init_and_modload(flags, console ? SWITCH_TRUE : SWITCH_FALSE, &err); switch_core_init_and_modload(flags, SWITCH_FALSE, &err); switch_core_runtime_loop(!console); return 0; } ==================================================================== cheers, Xing On 22/11/11 16:47, Anthony Minessale wrote:
maybe your user does not have permissions to read and write the target install dir try to chown -R to your user on all of /usr/local/freeswitch
you might want to try things the other way around and embedd your app in FS rather than embed FS in your app.
On Tue, Nov 22, 2011 at 10:20 AM, xl127 <x.liu@hw.ac.uk <mailto:x.liu@hw.ac.uk>> wrote:
If I switch to root user I can successfully run my embedded FS app: FS_Embed. but it will fails if I run it as non-root user.
One thing I can think of to do is re-install FS as non-root. I tried but it failed to access /usr/lib/python2.7/site-packages/freeswitch.py due to the permissions.
On 22/11/11 16:08, Anthony Minessale wrote:
i know you needed apr, not sure, maybe try strace or gdb
On Tue, Nov 22, 2011 at 6:36 AM, xl127 <x.liu@hw.ac.uk <mailto:x.liu@hw.ac.uk>> wrote:
Thanks for the advice!
I tried it but still got the same error.
I added the #include <apr_general.h> and found it from /usr/local/sr/freeswitch/libs/apr/include rather than from the installed directory /usr/local/freeswitch. Hope it is the right one.
any more clues?
On 22/11/11 01:38, Anthony Minessale wrote:
try
if (apr_initialize() != SWITCH_STATUS_SUCCESS) { fprintf(stderr, "FATAL ERROR! Could not initialize APR\n"); return 255; }
early on in main()
On Mon, Nov 21, 2011 at 1:12 PM, xl127 <x.liu@hw.ac.uk <mailto:x.liu@hw.ac.uk>> wrote:
Hello,
Following the instructions in http://wiki.freeswitch.org/wiki/Embedding_FreeSWITCH I am trying to use Embedded FreeSwitch.
I installed FS in Fedora linux as a root user in /usr/local/freeswitch. Now as non-root user, I compiled following codes:
#include <switch.h> int main(int argc, char** argv) { switch_core_flag_t flags = SCF_USE_SQL; bool console = true; const char *err = NULL; switch_core_set_globals(); switch_core_init_and_modload(flags, console ? SWITCH_TRUE : SWITCH_FALSE, &err); switch_core_runtime_loop(!console); return 0; }
And copy the executable and conf, mod, contents of lib of the installed FS to my $MyWorkingDir.
My directory structure looks like: MyWorkingDir--bin/ (contains my executable: FS_Embed) --conf/ --mod/ --lib/ --grammars --sounds --scripts --log (I also tried to copy the contents of lib directory into MyWorkingDir)
When I run my embedded FS: ./FS_Embed, I got error
2011-11-21 18:46:26.606783 [INFO] switch_event.c:631 Activate Eventing Engine. 2011-11-21 18:46:26.617941 [DEBUG] switch_event.c:610 Create event dispatch thread 0 FS_Embed: src/switch_xml.c:2225: switch_xml_open_cfg: Assertion `MAIN_XML_ROOT != ((void *)0)' failed. Aborted (core dumped)
and occasionally on another run, I got error:
2011-11-21 16:56:51.756040 [INFO] switch_event.c:631 Activate Eventing Engine. 2011-11-21 16:56:51.767198 [DEBUG] switch_event.c:610 Create event dispatch thread 0 Segmentation fault (core dumped)
It looks like there are some things wrong with my Environment Setup for Embedded FS, but after a while of checking/trying/googling I couldn't find what's wrong.
Any advice please?
Many thanks! Xing
-- Heriot-Watt University is a Scottish charity registered under charity number SC000278.
Heriot-Watt University is the Sunday Times Scottish University of the Year 2011-2012
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@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@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900 <tel:%2B19193869900>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
------------------------------------------------------------------------
MailScanner Signature HW *Heriot-Watt University is the Sunday Times
Scottish University of the Year 2011-2012 *
Heriot-Watt University is a Scottish charity registered under charity number SC000278.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@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@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900 <tel:%2B19193869900>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
------------------------------------------------------------------------
MailScanner Signature HW *Heriot-Watt University is the Sunday Times Scottish University of the Year 2011-2012*
Heriot-Watt University is a Scottish charity registered under charity number SC000278.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@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@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Heriot-Watt University is a Scottish charity registered under charity number SC000278. Heriot-Watt University is the Sunday Times Scottish University of the Year 2011-2012
participants (4)
-
Anthony Minessale
-
Hynek Cihlar
-
Peter Olsson
-
xl127