It is reasonably expensive but I need to maintain the connection to process other tasks, like a failover to the backup CTI server and other maintenance type things. The CTI server also sends events asynchronously to the clients which could possible arrive slightly before the call. If I do not maintain a connection I would then have to request the data, which would add even more delay.

It looks like Asterisk-java implements FastAGI, which takes care of the wrapper and communication protocol for me which will simplify the design and coding times.


Bryan Sant wrote:

I'm guessing that establishing the CTI connection is expensive and you
don't want to re-establish the connection each time a phone call comes
in.  Modern JVMs start up very quickly -- there may be between a 0.10
to 0.25 second delay in starting Sun's 1.5 JVM.  If reconnecting to
the CTI server doesn't take much time, then you may want to consider
allowing a new java process to be spawned for each call.

In any case, if you want to keep the java program running, I would
suggest writing a wrapper program that can be spawned quickly that
will interface with your long-running java app.  The method of
communication between the two would be named pipes.  Create named
pipes for stdin, stdout, and stderr.  The picture would look like
this:

AGI >>  wrapper >> pipes >> java program.

Say you did:  mkfifo my_stdin; mkfifo my_stdout; mkfifo my_stderr

So your wrapper would write its stdin data to the "my_stdin" pipe. Your java app would read in input from that file, process it, and then
write responses out to either "my_stdout" or "my_stderr" pipes.  The
wrapper program would be reading both of the output pipes and would
dump the contents it reads to its proper stdout/stderr.

Once a call transaction is done, your java app would then send some
kind of EOF token to say "my_stderr" and the wapper would intercept
that and quit.  AGI should be happy that processes are spawning and
exiting per transaction, Java is always running with its CTI
connection, and the wrapper just needs to be dumb and forward things
back and forth.

-Bryan
.-----------------------------------.
| This has been a P.L.U.G. mailing. |
|      Don't Fear the Penguin.      |
|  IRC: #utah at irc.freenode.net   |
`-----------------------------------'

.-----------------------------------.
| This has been a P.L.U.G. mailing. |
|      Don't Fear the Penguin.      |
|  IRC: #utah at irc.freenode.net   |
`-----------------------------------'

Reply via email to