According to the documentation, the JTAPI implementation is threaded so you can do nasty things in an event callback.
 
I recently deployed a call monitoring solution (quite a complex beast.. it can keep records of all calls and performs number lookups in various data sources) for quite a large installation (so far I've been dealing with 100-300 phones.. now we're looking at over 1000)
 
Those lookups can be quite involved.. and right now they're done in the callbacks for the appropriate CallEvs (basically I loop through the callsevs and have a method to handle each). Now... today I saw how the poor thing starts up.. not only does it eat up a lot of resources, but after going through the first 50 or so phones, it gets slower and slower and slower (part of the initialization is also loading the phone config from axl since I need information like what lines there are, the locale, extension mobility and some other stuff).
 
I had to do some modifs on the installation (attach another data source) and in order to be able to test more quickly I created a new app user to monitor just one phone and tested with that. Then, at the end I switched back the old app user but at some point I had to go and I didn't get callevs for my testphone yet - I haven't heard anything so far about the whole thing not working if you give it enough time (it's been running for over a month now attached to just a single data source) - but this has me worried so I'm wondering... are there any best practices when dealing with a large installation?
 
E.g. should I take the time to switch over any processing that accesses external data sources to their own threads (actually.. I'd go for a threadpool with an apropriate size since it seems more appropriate than creating threads all over the place for short running tasks).. are there any guideslines as to what you can safely process in the callbacks and what you should do in another thread?
 
Also, and I've noted that before... could it be that those threaded callbacks have their own error catching mechanism? sometimes when I have a
try
{
do something that may fail
}
catch (Exception e)
{
log the exception
}
 
the code seems to abort right in the middle of the try block without hitting the catch block..
when I run the same code in a non jtapi app, I'd get into the catch block with say a nullpointer exception or something nasty like it - but when inside the callback.. I get nothing at all.. no errors are dumped anywhere (the only thing I didn't do is turn on jtapi logging all the way)... is there something catching those errors on the sly without teling me anything about it?

Hi,
 
I sometimes experience deadlock issues in Cisco jtapi.jar when having multiple observers on the same device and a heavy load on my application server during application startup (during cti observers are registered).
 
This might also be the cause why your code is stuck in middle of the try block.
 
If you run your application in linux you can send a QUIT signal to the JVM to do a thread dump (which includes a deadlock detection).
I simply do a "killall -QUIT java" and then check the logs for something like:
 

Found one Java-level deadlock:
=============================
"ObserverThread(com.andtek.andphone.JTAPIThread$MyProviderObserver@5f0e7d)":
  waiting to lock monitor 0x088819b0 (object 0x94461b68, a com.cisco.jtapi.RouteTerminalImpl),
  which is held by "APAS-JTAPIThread"
"APAS-JTAPIThread":
  waiting to lock monitor 0x087a4e40 (object 0x9446a3a8, a com.cisco.jtapi.RouteAddressImpl),
  which is held by "ObserverThread(com.andtek.andphone.JTAPIThread$MyProviderObserver@5f0e7d)"


Regards,
Stefan