We're working on a server to receive and handle JTAPI messages from CUCM. In the dev guide, I note that the default behavior of the Cisco JTAPI implementation spawns a new thread for each observer:
"Normally, when an application adds a new observer to a JTAPI object, the Cisco JTAPI implementation creates an event queue and an accompanying worker thread to service the new observer. If the same observer is added to another object, its queue and thread are reused; in effect, every unique observer object has a single queue and worker thread"
The problem with this is that we're going be monitoring up to 10,000 objects (addresses/terminals/calls), and I'd really like to avoid starting that many threads. I know that we can implement the CiscoSynchronousObserver Interface to turn off this behavior, and then we can just spawn threads as we need them to do time consuming operations--this is the direction I'm leaning right now.
My question is this: has anyone written an app that monitors 10,000 or more JTAPI objects using the default behavior (i.e., spawning a new thread for each observer)? If so, what how did the server perform with so many threads? What type of server did you use (Linux or Windows)? Are there any recommendations regarding Best Practices for monitoring so many objects?
Thanks,
Scott
