[ERR] switch_cpp:910 object is not initalized
Hi there, I have an application written in mod_managed that receives a call, originates a call and then bridges the call when the user answers. This app will be extended to call several recipients and offer several chooses when a user answers (so I can not use the stock group_confirm functionality) I am load testing my application with SIPP. At a low cps the application reports no errors. As I increase the call rate I see: [ERR] switch_cpp:910 object is not initalized error message reported by FS. Line 910 seems to coorolate to a Session.Ready() request. To avoid accessing sessions that no longer exist I set my managed session = null in the hanguphook. I am a bit worried by this, because I am thinking this is indicative of a threading issue - i.e. I am not talking to the session I think I am tallking to. Is the Managed session thread safe? Are there any common gotchas? Also should I worry too much about this "object is not initalized" error? Will they cause an issue. On the plus side I can pump 80,000 calls at 5-10 cps through this system with no hung/orphaned channels - so that makes me think the system is ok. Its just those pesky error reports :) Any insight would be welcome. Thanks Phil
Are you sure the very thing you are doing by setting the manages session to null is not what is causing the error? Just a thought :) -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/ERR-switch-cpp-910-object-is-n... Sent from the freeswitch-users mailing list archive at Nabble.com.
Jeff, In my session hanguphook I call: if (Session != null && Session.HookState == switch_channel_state_t.CS_HANGUP) { Session = null; } All calls to the session in my app are as follows: if (Session != null && Session.Ready()) This is to prevent calls to dead FS sessions. Without this, the Session object exists, but calling it on a hungup session (even calling Session.Ready()) causes the object not found error. This is under load. Maybe it is timing issue. I don't need to do this with just a couple of calls. Does that make any sense? Hopefully I am not completely off base here? I read elsewhere in this list that the HangupHook does not fire 100% of the time - Anthony has just pushed change. I will check it with that. Phil On Tue, Jul 27, 2010 at 3:21 PM, Jeff Lenk <jeff@jefflenk.com> wrote:
Are you sure the very thing you are doing by setting the manages session to null is not what is causing the error?
Just a thought :) -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/ERR-switch-cpp-910-object-is-n... Sent from the freeswitch-users mailing list archive at Nabble.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
Its probably cases where the call setup didn't work. Be careful of how much you bring into your script because doing so will move some of the burden handled by efficient c code into the heavy wrapped higher level code. Fyi, you can use the regular group confirm to execute an app which could be a managed app in place of the dtmf check. Dgroup_confirm_key=exec group_confirm_file=<app> <args> Also there is loder documentation that won't die that suggests to create a session the session originate rather than just feeding a dial string to the constructor and checking if its ready on the following line. On Jul 27, 2010 1:47 PM, "Phillip Jones" <pjintheusa@gmail.com> wrote: Hi there, I have an application written in mod_managed that receives a call, originates a call and then bridges the call when the user answers. This app will be extended to call several recipients and offer several chooses when a user answers (so I can not use the stock group_confirm functionality) I am load testing my application with SIPP. At a low cps the application reports no errors. As I increase the call rate I see: [ERR] switch_cpp:910 object is not initalized error message reported by FS. Line 910 seems to coorolate to a Session.Ready() request. To avoid accessing sessions that no longer exist I set my managed session = null in the hanguphook. I am a bit worried by this, because I am thinking this is indicative of a threading issue - i.e. I am not talking to the session I think I am tallking to. Is the Managed session thread safe? Are there any common gotchas? Also should I worry too much about this "object is not initalized" error? Will they cause an issue. On the plus side I can pump 80,000 calls at 5-10 cps through this system with no hung/orphaned channels - so that makes me think the system is ok. Its just those pesky error reports :) Any insight would be welcome. Thanks Phil _______________________________________________ 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, Thanks for the reply. Point about C vs managed well taken. Can you explain this line though:
Also there is loder documentation that won't die that suggests to create a session the session originate rather than just feeding a dial string to the constructor and checking if its ready on the following line.
I have read it a couple of times but I am not following. Thanks Phil On Tue, Jul 27, 2010 at 3:53 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
Its probably cases where the call setup didn't work. Be careful of how much you bring into your script because doing so will move some of the burden handled by efficient c code into the heavy wrapped higher level code.
Fyi, you can use the regular group confirm to execute an app which could be a managed app in place of the dtmf check. Dgroup_confirm_key=exec group_confirm_file=<app> <args>
Also there is loder documentation that won't die that suggests to create a session the session originate rather than just feeding a dial string to the constructor and checking if its ready on the following line.
On Jul 27, 2010 1:47 PM, "Phillip Jones" <pjintheusa@gmail.com> wrote:
Hi there,
I have an application written in mod_managed that receives a call, originates a call and then bridges the call when the user answers. This app will be extended to call several recipients and offer several chooses when a user answers (so I can not use the stock group_confirm functionality)
I am load testing my application with SIPP. At a low cps the application reports no errors. As I increase the call rate I see:
[ERR] switch_cpp:910 object is not initalized error message reported by FS.
Line 910 seems to coorolate to a Session.Ready() request.
To avoid accessing sessions that no longer exist I set my managed session = null in the hanguphook.
I am a bit worried by this, because I am thinking this is indicative of a threading issue - i.e. I am not talking to the session I think I am tallking to. Is the Managed session thread safe? Are there any common gotchas?
Also should I worry too much about this "object is not initalized" error? Will they cause an issue.
On the plus side I can pump 80,000 calls at 5-10 cps through this system with no hung/orphaned channels - so that makes me think the system is ok.
Its just those pesky error reports :)
Any insight would be welcome.
Thanks
Phil
_______________________________________________ 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
_______________________________________________ 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
sorry, I was on my phone. "older" documentation that has been long deprecated teaches people to do: . or -> depending on the language for method separators foo = new Session(); then foo.originate(dialstr); the right way is foo = new Session(dialstr, inbound_session); inbound_session is optional. On Tue, Jul 27, 2010 at 3:09 PM, Phillip Jones <pjintheusa@gmail.com> wrote:
Anthony,
Thanks for the reply. Point about C vs managed well taken.
Can you explain this line though:
Also there is loder documentation that won't die that suggests to create a session the session originate rather than just feeding a dial string to the constructor and checking if its ready on the following line.
I have read it a couple of times but I am not following.
Thanks
Phil On Tue, Jul 27, 2010 at 3:53 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
Its probably cases where the call setup didn't work. Be careful of how much you bring into your script because doing so will move some of the burden handled by efficient c code into the heavy wrapped higher level code.
Fyi, you can use the regular group confirm to execute an app which could be a managed app in place of the dtmf check. Dgroup_confirm_key=exec group_confirm_file=<app> <args>
Also there is loder documentation that won't die that suggests to create a session the session originate rather than just feeding a dial string to the constructor and checking if its ready on the following line.
On Jul 27, 2010 1:47 PM, "Phillip Jones" <pjintheusa@gmail.com> wrote:
Hi there,
I have an application written in mod_managed that receives a call, originates a call and then bridges the call when the user answers. This app will be extended to call several recipients and offer several chooses when a user answers (so I can not use the stock group_confirm functionality)
I am load testing my application with SIPP. At a low cps the application reports no errors. As I increase the call rate I see:
[ERR] switch_cpp:910 object is not initalized error message reported by FS.
Line 910 seems to coorolate to a Session.Ready() request.
To avoid accessing sessions that no longer exist I set my managed session = null in the hanguphook.
I am a bit worried by this, because I am thinking this is indicative of a threading issue - i.e. I am not talking to the session I think I am tallking to. Is the Managed session thread safe? Are there any common gotchas?
Also should I worry too much about this "object is not initalized" error? Will they cause an issue.
On the plus side I can pump 80,000 calls at 5-10 cps through this system with no hung/orphaned channels - so that makes me think the system is ok.
Its just those pesky error reports :)
Any insight would be welcome.
Thanks
Phil
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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 <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.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<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
Thanks for that. Is this supported in mod_managed? The contructor overloads on ManagedSession are: ManagedSession() ManagedSession(string uuid) and ManagedSession(SWIGTYPE_switch_core_session) On Tue, Jul 27, 2010 at 5:42 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
sorry, I was on my phone.
"older" documentation that has been long deprecated teaches people to do:
. or -> depending on the language for method separators
foo = new Session(); then foo.originate(dialstr);
the right way is
foo = new Session(dialstr, inbound_session);
inbound_session is optional.
On Tue, Jul 27, 2010 at 3:09 PM, Phillip Jones <pjintheusa@gmail.com>wrote:
Anthony,
Thanks for the reply. Point about C vs managed well taken.
Can you explain this line though:
Also there is loder documentation that won't die that suggests to create a session the session originate rather than just feeding a dial string to the constructor and checking if its ready on the following line.
I have read it a couple of times but I am not following.
Thanks
Phil On Tue, Jul 27, 2010 at 3:53 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
Its probably cases where the call setup didn't work. Be careful of how much you bring into your script because doing so will move some of the burden handled by efficient c code into the heavy wrapped higher level code.
Fyi, you can use the regular group confirm to execute an app which could be a managed app in place of the dtmf check. Dgroup_confirm_key=exec group_confirm_file=<app> <args>
Also there is loder documentation that won't die that suggests to create a session the session originate rather than just feeding a dial string to the constructor and checking if its ready on the following line.
On Jul 27, 2010 1:47 PM, "Phillip Jones" <pjintheusa@gmail.com> wrote:
Hi there,
I have an application written in mod_managed that receives a call, originates a call and then bridges the call when the user answers. This app will be extended to call several recipients and offer several chooses when a user answers (so I can not use the stock group_confirm functionality)
I am load testing my application with SIPP. At a low cps the application reports no errors. As I increase the call rate I see:
[ERR] switch_cpp:910 object is not initalized error message reported by FS.
Line 910 seems to coorolate to a Session.Ready() request.
To avoid accessing sessions that no longer exist I set my managed session = null in the hanguphook.
I am a bit worried by this, because I am thinking this is indicative of a threading issue - i.e. I am not talking to the session I think I am tallking to. Is the Managed session thread safe? Are there any common gotchas?
Also should I worry too much about this "object is not initalized" error? Will they cause an issue.
On the plus side I can pump 80,000 calls at 5-10 cps through this system with no hung/orphaned channels - so that makes me think the system is ok.
Its just those pesky error reports :)
Any insight would be welcome.
Thanks
Phil
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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 <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.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<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ 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
yes string uuid can also be string dialstring On Wed, Jul 28, 2010 at 9:20 AM, Phillip Jones <pjintheusa@gmail.com> wrote:
Thanks for that.
Is this supported in mod_managed?
The contructor overloads on ManagedSession are:
ManagedSession() ManagedSession(string uuid) and ManagedSession(SWIGTYPE_switch_core_session)
On Tue, Jul 27, 2010 at 5:42 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
sorry, I was on my phone.
"older" documentation that has been long deprecated teaches people to do:
. or -> depending on the language for method separators
foo = new Session(); then foo.originate(dialstr);
the right way is
foo = new Session(dialstr, inbound_session);
inbound_session is optional.
On Tue, Jul 27, 2010 at 3:09 PM, Phillip Jones <pjintheusa@gmail.com>wrote:
Anthony,
Thanks for the reply. Point about C vs managed well taken.
Can you explain this line though:
Also there is loder documentation that won't die that suggests to create a session the session originate rather than just feeding a dial string to the constructor and checking if its ready on the following line.
I have read it a couple of times but I am not following.
Thanks
Phil On Tue, Jul 27, 2010 at 3:53 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
Its probably cases where the call setup didn't work. Be careful of how much you bring into your script because doing so will move some of the burden handled by efficient c code into the heavy wrapped higher level code.
Fyi, you can use the regular group confirm to execute an app which could be a managed app in place of the dtmf check. Dgroup_confirm_key=exec group_confirm_file=<app> <args>
Also there is loder documentation that won't die that suggests to create a session the session originate rather than just feeding a dial string to the constructor and checking if its ready on the following line.
On Jul 27, 2010 1:47 PM, "Phillip Jones" <pjintheusa@gmail.com> wrote:
Hi there,
I have an application written in mod_managed that receives a call, originates a call and then bridges the call when the user answers. This app will be extended to call several recipients and offer several chooses when a user answers (so I can not use the stock group_confirm functionality)
I am load testing my application with SIPP. At a low cps the application reports no errors. As I increase the call rate I see:
[ERR] switch_cpp:910 object is not initalized error message reported by FS.
Line 910 seems to coorolate to a Session.Ready() request.
To avoid accessing sessions that no longer exist I set my managed session = null in the hanguphook.
I am a bit worried by this, because I am thinking this is indicative of a threading issue - i.e. I am not talking to the session I think I am tallking to. Is the Managed session thread safe? Are there any common gotchas?
Also should I worry too much about this "object is not initalized" error? Will they cause an issue.
On the plus side I can pump 80,000 calls at 5-10 cps through this system with no hung/orphaned channels - so that makes me think the system is ok.
Its just those pesky error reports :)
Any insight would be welcome.
Thanks
Phil
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ 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 <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.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<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
_______________________________________________ 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
_______________________________________________ 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 <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.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<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
participants (3)
-
Anthony Minessale
-
Jeff Lenk
-
Phillip Jones