Thanks for the reply. Neat ideas there, but a couple of issues.
1. Don't want to have to jump around between the FastAGI and the dial plan. Our
plan is to have NO customer data in the dialplan, as all data will be contained
within MySQL. We don't want to have to make _any_ edits to the dial plan when a
new customer is added. It's a provisioning nightmare to have to do this. It
also may not be a Dial() command that gets excuted for a given number dialled.
It might be Meetme(), Queue() or something else. Jumping back into the dialplan
and then executing the right command would be hard to maintain. It'd be helpful
if Asterisk accepted something like the following, which would make it easier,
but it doesn't...
exten => _X.,1,AGI(//localhost/script.py)
exten => _X.,2,${APP}( ${ARGS} )
We have no customer data in the dialplan, everything is done through mysql.
There are 2 basic ways (at least) to use FastAGI when you dont want to
have a multithreaded FastAGI server.
1. Create some 'helper' contexts in the dialplan to handle
applications/actions that may take some time (like meetme,dial a.s.o.).
Let the FastAGI server set some channel variables that you may need
(like Destination number, which CallerID to use aso) and ofcourse the
context before returning to the dialplan.
2.Use a modified version of Asterisk.pm which is build around select
and nonblocking i/o that uses event driven callbacks into your
application code.(yes threadsafe, it sleeps on a select call until
events then create the callback. Since your not familiar with select i
would recommend using method 1.
What about findme/followme functionality? Are we going to have to jump
backwards and forwards between the agi and the dialplan each time (all the
while maintaining the last number tried in the agi) a new number is tried? We
could return ALL the numbers to try at once from the AGI I guess, kinda like
${NUM1}, ${NUM2}, ${NUM3} etc. Oh YUCK!
2. How did you get around the fact that it's quite clearly documented that the
perl DBI is _not_ thread safe?
You can easily use a perl distro compiled without multithread enabled
eventhough it shouldn't be needed. Again read up on perl IO::select.
You sleep waiting for event input, execute the job and then sleep
again. No multitread needed. You may issue sql request that takes 20
or 50 msec and nothing else is going on within a single server during
that time so no re-entrance into unsafe DBI code. It also means other
calls are not being served from that server during this period that why
I pointed you to use the server interleaving.
3. I don't have a high enough confidence in the stability of either perl or
python threading, to allow the FastAGI server to potentially receive several
dozen calls, and therefore several threads each. If the FastAGI server crashes,
you lost the ability to place _any_ calls.
As described above: no threading needed within the server. We have AGI
servers that processes 10K+ calls per day per server ( some of the
servers has 15K perl lines ) they never crash but they are started out
of /etc/inittab anyway (just in case)
4. Using select() system calls is a little beyond my abilities...
Doug.
I hope to get some time to do a cleanup on my framework for solution 2
above, it might benefit some other people that like to use agi-perl
b.r.
Freddi
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
