'outbound' IVR with JavaScript - garbage collection issues
My application dials 100's of numbers, waits for user to answer, plays a .wav file, and waits for some DTMF. I'm using the Javascript interface to do all this now (actually it's a Perl script which launches JS by sending jsrun commands through the RPC XML interface). But at high call rates, I'm running into JS garbage collection issues fairly quickly. At 10 calls per second, after about 300 calls it looks like JS GC kicks in and runs for like 45 seconds, during which time I can't launch any more calls with JS (RPC XML accepts them, but then they are getting Q'd up inside the spidermonkey code, and eventually some of them fail because GC is taking so long, etc). Is JS the best way to do this application, and if so, any ideas how I workaround the GC? If not, what is the alternative (where I would still have access to the simple programming interface that JS gives me, as far as all the session. functions like waitForAnswer, streamFile, getDigits). Tom =============== tuhl@ix.netcom.com
It looks like something is not turning off garbage collection that should be (things that run for a long time should). Try instead of launching the call from js, to do api originate with the ignore_early_media var set to true. This should not run your extension until after the call is answered. If your still having garbage collection issues after this, let us know. You might even get away with using the confirm keys on originate to do the digit collection depending on how complicated your ivr is. Mike On Jan 23, 2008, at 8:55 PM, tuhl@ix.netcom.com wrote:
My application dials 100's of numbers, waits for user to answer, plays a .wav file, and waits for some DTMF. I'm using the Javascript interface to do all this now (actually it's a Perl script which launches JS by sending jsrun commands through the RPC XML interface). But at high call rates, I'm running into JS garbage collection issues fairly quickly. At 10 calls per second, after about 300 calls it looks like JS GC kicks in and runs for like 45 seconds, during which time I can't launch any more calls with JS (RPC XML accepts them, but then they are getting Q'd up inside the spidermonkey code, and eventually some of them fail because GC is taking so long, etc).
Is JS the best way to do this application, and if so, any ideas how I workaround the GC? If not, what is the alternative (where I would still have access to the simple programming interface that JS gives me, as far as all the session. functions like waitForAnswer, streamFile, getDigits).
Tom
=============== tuhl@ix.netcom.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
It looks like Anthony just committed a fix for this in svn revision 7343. Please give it a try, but my earlier suggestions still stand on a lighter way to do what you are attempting. Mike On Jan 23, 2008, at 9:52 PM, Michael Jerris wrote:
It looks like something is not turning off garbage collection that should be (things that run for a long time should). Try instead of launching the call from js, to do api originate with the ignore_early_media var set to true. This should not run your extension until after the call is answered. If your still having garbage collection issues after this, let us know. You might even get away with using the confirm keys on originate to do the digit collection depending on how complicated your ivr is.
Mike
On Jan 23, 2008, at 8:55 PM, tuhl@ix.netcom.com wrote:
My application dials 100's of numbers, waits for user to answer, plays a .wav file, and waits for some DTMF. I'm using the Javascript interface to do all this now (actually it's a Perl script which launches JS by sending jsrun commands through the RPC XML interface). But at high call rates, I'm running into JS garbage collection issues fairly quickly. At 10 calls per second, after about 300 calls it looks like JS GC kicks in and runs for like 45 seconds, during which time I can't launch any more calls with JS (RPC XML accepts them, but then they are getting Q'd up inside the spidermonkey code, and eventually some of them fail because GC is taking so long, etc).
Is JS the best way to do this application, and if so, any ideas how I workaround the GC? If not, what is the alternative (where I would still have access to the simple programming interface that JS gives me, as far as all the session. functions like waitForAnswer, streamFile, getDigits).
Tom
=============== tuhl@ix.netcom.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
participants (2)
-
Michael Jerris
-
tuhl＠ix.netcom.com