[Freeswitch-users] FreeSWITCH-users Digest, Vol 103, Issue 247

Fri Jan 23 19:53:25 MSK 2015

You have some limits on your system causing thread create failure.  Look at your ulimits or if you are running virtualized, all the related limits there.

> On Jan 22, 2015, at 7:13 PM, Ahmed Habiba <ahabiba at gmail.com> wrote:
> 
> Thank you really Michael,
> 
> I go through logs and I find the below, the question why could lead to that, the machine is 16 core??
> 
> 2015-01-23 02:06:59.593497 [CRIT] switch_core_session.c:1780 Thread Failure!
> 2015-01-23 02:06:59.593497 [CRIT] switch_core_session.c:1713 LUKE: I'm hit, but not bad.
> 2015-01-23 02:06:59.593497 [CRIT] switch_core_session.c:1714 LUKE'S VOICE: Artoo, see what you can do with it. Hang on back there....
> Green laserfire moves past the beeping little robot as his head turns.  After a few beeps and a twist of his mechanical arm,
> Artoo reduces the max sessions to 346 thus, saving the switch from certain doom.
> 
> 
> From: Michael Jerris <mike at jerris.com <mailto:mike at jerris.com>>
> To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org <mailto:freeswitch-users at lists.freeswitch.org>>
> Date: January 23, 2015 at 2:51:18 AM GMT+3
> Reply-To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org <mailto:freeswitch-users at lists.freeswitch.org>>
> Subject: Re: [Freeswitch-users] Session Limit
> 
> 
> look at the logs, if you extend beyond your resources and freeswitch can't start threads among other things, it will lower your session limit.
> 
>> On Jan 22, 2015, at 6:47 PM, Ahmed Habiba <ahabiba at gmail.com <mailto:ahabiba at gmail.com>> wrote:
>> 
>> Dears,
>> 
>> kindly Im facing some issue with concurrent session limit, below is the status showing the maximum sessions of 355, however I set maximum sessions to 10000, you kind help to identify why freeswitch use lower limit than the configured one will be appreciated.
>> 
>> /etc/freeswitch# fs_cli -x "status"
>> UP 0 years, 0 days, 0 hours, 19 minutes, 2 seconds, 490 milliseconds, 264 microseconds
>> FreeSWITCH (Version 1.5.8b+git git 35f2bcc 2014-02-12 23:33:16Z 64bit) is ready
>> 345 session(s) since startup
>> 345 session(s) - peak 345, last 5min 345 
>> 0 session(s) per Sec out of max 1000, peak 66, last 5min 0 
>> 335 session(s) max
>> min idle cpu 0.00/62.00
>> Current Stack Size/Max 240K/8192K
>> 
>> switch.conf.xml:
>> 
>>     <param name="max-sessions" value="10000"/>
>>     <!--Most channels to create per second -->
>>     <param name="sessions-per-second" value="1000”/>
> 
> 
> 
> 
> From: Muhammad Naseer Bhatti <nbhatti at gmail.com <mailto:nbhatti at gmail.com>>
> To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org <mailto:freeswitch-users at lists.freeswitch.org>>, Michael Jerris <mike at jerris.com <mailto:mike at jerris.com>>
> Date: January 23, 2015 at 2:58:31 AM GMT+3
> Reply-To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org <mailto:freeswitch-users at lists.freeswitch.org>>
> Subject: Re: [Freeswitch-users] Unable to access channel vars after session terminates evens with set_zombie_exec()
> 
> 
> 
> Setting inline will have performance penalty? 
> 
> —
> Thanks,
> Muhammad Naseer Bhatti
> 
> From: Michael Jerris <mike at jerris.com> <mailto:mike at jerris.com>
> Reply: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>> <mailto:freeswitch-users at lists.freeswitch.org>
> Date: January 23, 2015 at 2:11:48 AM
> To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>> <mailto:freeswitch-users at lists.freeswitch.org>
> Subject:  Re: [Freeswitch-users] Unable to access channel vars after session terminates evens with set_zombie_exec() 
> 
>> if you set them using inline they will be set during routing state, before it goes to execute.  Once it is in execute state, it checks status between every action.
>> 
>>> On Jan 22, 2015, at 3:53 PM, Muhammad Naseer Bhatti <nbhatti at gmail.com <mailto:nbhatti at gmail.com>> wrote:
>>> 
>>> 
>>> I need to access some channel variables being set in the dialplan, but the channel is already hanged up too quick, ORIGINATOR_CANCEL. Since the session was still setting up the channel variables. I have tried app, set_zombie_exec but still not able to see any channel vars set in the dial plan. Am i doing something wrong or if there is a better way to see the channel vars if the session terminates too soon?
>>> 
>>> With: git a067a49
>>> 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Regex (PASS) [internal] destination_number(1786866) =~ /$/ break=on-false
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action set_zombie_exec() 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action set(hangup_after_bridge=true) 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action set(continue_on_fail=true) 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action set(fail_on_single_reject=USER_BUSY,NO_ANSWER,NO_USER_RESPONSE,ORIGINATOR_CANCEL) 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action set(disable_hold=true) 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action set(failed_json_cdr_prefix=failed_cdr_index) 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action set(debug_cdr=0) 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action set(debug_cdr_sql=1) 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action set(cust_default_lrn=intra) 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action set(cust_lrn_dip_cost=0.01817) 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action set(cust_jurisdiction=INTRASTATE) 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action limit(hash random_xgw 0.0.0.0 10/1 !FACILITY_REJECTED) 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action limit_execute(hash outbound random_xgw 20 bridge [enable_heartbeat_events=5,nibble_rate=0.2192,nibble_increment=5,nibble_account=AB8KA191,carrier_switch=random_xgw,carrier_switch_id=1,carrier_ratecard_id=2,carrier_rate_rev=1,carrier_rate_type=lrn,carrier_id=1,carrier_connection_cost=0,carrier_rate=0.0119,carrier_interstate_cost=0.0119,carrier_intrastate_cost=0.0119,carrier_enable_billing=t,carrier_call_increment=1,carrier_min_duration=5,carrier_balance=17099.88924]sofia/gateway/random_xgw/1786866) 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action limit(hash switch02 0.0.0.0 10/1 !FACILITY_REJECTED) 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action limit_execute(hash outbound switch02 20 bridge [enable_heartbeat_events=5,nibble_rate=0.2192,nibble_increment=5,nibble_account=AB8KA191,carrier_switch=switch02,carrier_switch_id=3,carrier_ratecard_id=2,carrier_rate_rev=1,carrier_rate_type=lrn,carrier_id=1,carrier_connection_cost=0,carrier_rate=0.0119,carrier_interstate_cost=0.0119,carrier_intrastate_cost=0.0119,carrier_enable_billing=t,carrier_call_increment=1,carrier_min_duration=5,carrier_balance=17099.88924]sofia/gateway/switch02/1786866) 
>>> Dialplan: sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> Action hangup() 
>>> 2015-01-22 11:47:14.856013 [DEBUG] switch_core_state_machine.c:216 (sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26>) State Change CS_ROUTING -> CS_EXECUTE
>>> 2015-01-22 11:47:14.856013 [DEBUG] switch_core_session.c:1388 Send signal sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> [BREAK]
>>> 2015-01-22 11:47:14.856013 [DEBUG] switch_core_state_machine.c:528 (sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26>) State ROUTING going to sleep
>>> 2015-01-22 11:47:14.856013 [DEBUG] switch_core_state_machine.c:472 (sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26>) Running State Change CS_EXECUTE
>>> 2015-01-22 11:47:14.856013 [DEBUG] sofia.c:6614 Channel sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> entering state [terminated][487]
>>> 2015-01-22 11:47:14.856013 [NOTICE] sofia.c:7530 Hangup sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> [CS_EXECUTE] [ORIGINATOR_CANCEL]
>>> 2015-01-22 11:47:14.856013 [DEBUG] switch_channel.c:3222 Send signal sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> [KILL]
>>> 2015-01-22 11:47:14.856013 [DEBUG] switch_core_session.c:1388 Send signal sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> [BREAK]
>>> 2015-01-22 11:47:14.856013 [DEBUG] switch_core_state_machine.c:535 (sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26>) State EXECUTE
>>> 2015-01-22 11:47:14.856013 [DEBUG] mod_sofia.c:178 sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26> SOFIA EXECUTE
>>> 2015-01-22 11:47:14.856013 [DEBUG] switch_core_state_machine.c:535 (sofia/internal/9401404 at 10.211.55.26 <mailto:sofia/internal/9401404 at 10.211.55.26>) State EXECUTE going to sleep
>>>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150123/4a7fa1a5/attachment-0001.html 